API gateway security: central rules, clear trust boundaries

Which responsibility belongs where?

The division depends on your architecture. An early check can avoid unnecessary work, while a decision about a specific object needs its current context.

A gateway can handle authorisation if it reliably has the required context and alternative paths are protected accordingly. It is therefore wrong to deny it every permission decision in principle. More complex applications often combine coarse entry rules with finer service-level rules, however. OWASP describes both options and their limits. OWASP: Microservices Security.

Object authorisation and function permissions help determine the actual decision basis. ‘Token valid’ and ‘this invoice belongs to this user’ are different statements.

Protect downstream services from unintended direct access

If the service trusts only the gateway, an arbitrary other caller must not use the same access with self-supplied identity data. Check private and public addresses, internal routes, additional ports and earlier deployment paths from your API inventory.

A typical design restricts network access to the required path and has the service authenticate the calling service or proxy. Mutual TLS authentication or a suitable service-bound token may serve this purpose. The choice needs a managed identity and key lifecycle; a shared arbitrary header value is insufficient.

Some services are deliberately directly reachable too. The required rules must then also apply on that path. What matters is not whether a port is called closed, but whether an unauthorised call can achieve the same effect anywhere.

Checking the public gateway response does not reveal these internal paths. Evidence comes from configuration and controlled integration cases using your own identities.

Pass identity reliably

After authentication, the service needs correct context: who is calling, for which tenant and with which limited permissions? Establish which component creates these details and how the receiving component verifies their origin.

One possible design uses an internally signed, short-lived representation of the verified identity. The recipient checks issuer, validity and intended audience. Another lets each service validate an access token intended for it. Both need a clearly defined trust relationship; the choice depends on identity model and supported protocols. Do not invent an unverified cryptographic scheme for this.

Blindly forwarding an external token to every service expands its possible use and the number of places where it might be exposed. Conversely, a token name known only internally provides no protection without actual validation. JWT validation explains correct token checks.

At minimum, it must be clear that the client cannot freely set the claimed internal identity and the service accepts it only through the intended verified path. Remove or safely overwrite incoming external headers with internally reserved identity names at the boundary; ambiguous duplicates must not produce a different backend outcome.

Proxy headers are initially claims

Forwarding headers can carry the original client address, host and protocol. They become trustworthy only through a correctly configured proxy chain. If your application accepts arbitrary supplied values, they may influence links, redirects, secure-cookie decisions or IP-based limits.

Express demonstrates this dependency through trust proxy: with blanket trust, the last trusted proxy must reliably remove or overwrite the relevant X-Forwarded headers. Configuration based on a fixed hop count can also create misplaced trust where paths differ in length. Express: Behind proxies.

Do not copy a configuration line without drawing your own chain: public entry, any additional proxy, gateway, service. For each handover, define who sets the value and which direct peer the recipient accepts. Include proxies that route differently during rollout in testing.

The address from a correctly handled proxy header remains a network signal, not a reliable personal identity. Do not use it without further justification as a substitute for customer permissions or an organisation-wide quota.

Keep central rules consistent

Choose a clear owner for shared tasks. If gateway and application independently assemble CORS headers or error responses, contradictory responses may result. The CORS configuration guide covers the permission decision; for nginx, see the specific configuration guide.

Route changes can alter a policy's effect. Check together which external method and path reach the backend after rewriting and where authorisation applies. A new administration route should not accidentally inherit a more public general rule. Test actual mapping instead of inferring identical controls from similar route names.

Gateway features also have product boundaries. AWS explains, for example, that API keys in its Usage Plans should not serve as authentication or authorisation and their quotas are not guaranteed hard ceilings. This applies to that AWS feature; it is no blanket judgement on every API key. AWS: API Gateway Usage Plans.

A WAF or schema feature can detect and filter additional input. Without knowing the rule and context, this does not establish object, field or business permissions.

Decide failure and change handling in advance

What happens if the identity service or a central policy component is unavailable? For protected writes, a technical error must not silently mean permission. If your architecture caches decisions, clarify validity, revocation and acceptable age. A long-stored ‘allowed’ may perpetuate outdated permissions.

A gateway can also become a central failure point. Keep configuration and changes traceable, restrict administrative rights and protect its management interface. Its central position calls for careful operation; it is no automatic security property.

For changes, first test intended access with valid and invalid identities of your own. Add forbidden direct access, self-supplied internal headers, an alternative proxy chain and policy-decision failure. Check both the response and whether the backend operation actually ran.

No gateway configuration was changed or tested in operation for this article. Apply the decision process in your own authorised test environment.

Preserve a safe rollback path

Preserve the last tested configuration and associated identity-contract versions. Revert a faulty route or policy specifically. Temporarily exposing a backend publicly to bypass a gateway problem changes the architectural decision and requires its own safe alternative.

After switching, retest relevant permitted and forbidden paths. Correlate gateway and application so upstream success does not conceal a later business failure. Logging and monitoring brings these observations together.

The API Security Check observes public response characteristics. It tests no internal proxy trust chain, gateway administration or end-to-end authorisation decision. These promises require architecture, configuration and flow evidence of your own.

Next steps