A gateway check is not enough on its own. Use the gateway to reject clearly unauthorized requests at the edge, and make every service enforce access to its own protected operations, including calls from other internal services. Fine-grained decisions need context that only the service has.
What the OWASP guidance says
The OWASP Microservices Security Cheat Sheet separates two layers. Edge-level authorization uses gateway checks to reject unauthorized inbound requests, and it should also prevent direct access that bypasses the gateway. Service-level authorization means each service enforces access to its protected operations, including internal calls. The sheet adds that gateway checks do not establish that a downstream operation is authorized.
Why the gateway cannot do it all
A gateway sees a request path and a token. It rarely knows that invoice 4812 belongs to tenant B, or that this user may view but not refund. Those rules need resource and business context. Pushing them into the gateway either makes it a bottleneck or leaves them unchecked.
A second reason is the network. If any internal caller can reach a service directly, the gateway is just a suggestion. A compromised pod, a mistaken route or a test endpoint all skip the edge.
A split that works
- Gateway: authenticate, check token validity and coarse scope, rate limit, and reject malformed calls.
- Service: check that this caller, user and tenant may perform this action on this object.
- Network: make the service reachable only from the gateway and approved peers, using default deny network policy.
Keep policy consistent
As systems grow, the cheat sheet recommends shared, reviewed policies, with object, tenant and business rules enforced at the service. Copying rule code into twenty services drifts. A shared library or a policy engine with one reviewed rule set keeps the answers the same everywhere.
Test for the bypass
Write tests that call a service directly, without the gateway, using a valid token for the wrong tenant. Also test internal service to service calls that carry no user. If either succeeds when it should fail, the model has a gap.
Common mistakes
- Trusting a header the gateway adds, when internal callers could set the same header.
- Checking only that a token is valid, without checking it was meant for this service.
- Assuming internal means trusted.
For the identity side, read passing user context between services.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can a service skip authorization because the gateway already did it?
No. The OWASP sheet says gateway checks do not establish that a downstream operation is authorized.
What belongs at the gateway?
Coarse checks such as authentication and scope, plus blocking direct access that bypasses it.
Sources
Last reviewed: 19 October 2026.
