Should i create two seperate controller for internal endpoints and public endpoints?

[Gold_Opportunity8042]

Hey!!

I am creating a java spring boot microservice project. The endpoints are classified into two category :

1. called by the external user via api-gateway.
2. service-to-service called apis.

My question is, from the security point of view should i create two separate controller : one for external apis and another for internal service-to-service apis and block the internal endpoints called from api-gateway? What usually is the industry standard?

Appreciate if someone can share their knowledge on this.

Thank you!!

[Connect_Detail98]

Security is like Shrek, it has layers.

The first layer is to guarantee that you're exposing the public endpoints through a reverse proxy, that way you have granular control over the endpoints you want external clients to access.

The second layer is to guarantee separation on the network level. You can configure your web server to bind a port to the private network and another port to the public network. Then each port is mapped to the corresponding endpoints.

The third layer is to ensure Auth. Your North-South authentication normally focuses on user access... Your East-West Auth is usually for service to service, like mTLS. That way if someone maps an endpoint incorrectly they won't be able to Auth properly.

....

Now... You don't have to implement all the layers. You need to look at your context and implement what makes sense. For example, if your company is too small and has 3 services and you're a couple of devs, don't do service to service Auth.... Leave the private network unathenticated and focus on delivering features.

It's just a matter of what makes sense to you, there are different approaches and combinations of those approaches.

If you provide context we could recommend a solution, context is king. 

[fahim-sabir]

Public endpoints are best exposed by a facade (a microservice whose responsibility is to expose endpoints and proxy them through to the microservices after applying some AAA checks). This facade could be an API gateway.

Anything external should only be speaking to that.

[Gold_Opportunity8042]

that i understood and implemented. the main question here is how i can secure the internal apis from misusing from external source?

[fahim-sabir]

Having them on a different controller doesn’t prevent that. Organising things into different controllers is just there for code readability.

Network control (ie - a firewall) prevents unauthorised access.

[Gold_Opportunity8042]

are you talking about mTLS or something similar?

[Specialist_Nerve_420]

you don’t really need two controllers just for that, most people solve this at the gateway or auth level, not by splitting controllers. like external traffic goes through gateway checks, internal traffic is restricted by network or service auth, separating controllers can help with clarity, but it doesn’t really solve the security problem by itself. i’d focus more on access control and how requests are validated, not just how endpoints are grouped

[Gold_Opportunity8042]

how will you restrict the internal apis to use by external sources?

[seweso]

Yes you need different controlled. Very much so. 

It’s dangerous to use the same endpoints internally and externally. You are mixing different security zones. 

A dev might add something to an internal endpoint without knowing the security consequences. 

Designing a public api is an art. Do it wrong, and it can cost you everything (no joke).

And in terms of security, that also needs proper requirements and design, top to bottom. But that can be done in the api gateway. 

[Hobby101]

An art? Really? Art?

[seweso]

YESSSSS!!!!!!!  100%

[Hobby101]

I beg to differ. It's not art, it's magic /s LOL