An API gateway handles authentication, rate limiting and routing, which lets the services behind it stay simple. The security question is what those services do when a request arrives without passing through the gateway. In many estates the answer is that they trust it completely, so anyone who reaches the service directly is treated as authenticated.
Two paths, two sets of rules
Test the published route and the direct one. Services are often reachable inside the network on a private address, through a load balancer that was left listening, or from another workload in the same cluster. Where the service accepts a header such as an authenticated user identifier that the gateway is supposed to set, a direct caller can simply supply it. That is impersonation with no exploitation involved, and it is why internal position matters so much in a microservice estate. A service mesh helps here, and only where its policy is enforced rather than merely observed.
Headers the backend should not trust
Gateways add headers describing the caller, and backends read them as fact. The pattern to look for is any header carrying identity, role or source address that is not cryptographically bound to the request. If your service trusts an X-Forwarded-For value for allowlisting, a caller who sets it themselves reaches whatever that allowlist protects. The fix is to strip and reset these headers at the edge, and to have the backend verify a signed token rather than a plain header wherever the decision matters. Treat anything the gateway sets as untrusted input at the service, exactly as you would a query parameter.
“Ask your platform team a straightforward question: can I call this service without going through the gateway. If the answer needs investigation, that is your finding. In cloud estates the honest answer is usually yes from somewhere, whether a peered network, a container in the same namespace or a machine that has been in the account since before the gateway existed.”
William Fieldhouse, Director, Aardwolf Security Ltd
Limits that do not survive contact
Unrestricted resource consumption sits in the OWASP API Security Top 10 for 2023 because rate limits are easy to configure and easy to sidestep. Limits keyed on a client address fall to a rotating pool of addresses. Limits keyed on an API key fall to an attacker who registers several. Limits applied per endpoint miss the caller who spreads a scraping run across twenty endpoints. Test with realistic evasion rather than a burst from one address, and check whether exceeding a limit produces a useful error or an expensive one that ties up a backend thread.
Scoping a test that covers the architecture
Give the tester both perspectives. From outside, they exercise the gateway as a client would. From inside, with a foothold in the network or the cluster, they check what the services accept when the gateway is out of the picture. API penetration test servicescover the application logic on both paths, and external infrastructure penetration testing establishes whether the direct route is reachable from the internet, which is the case more often than architecture diagrams suggest.
Frequently asked questions about gateway testing
These questions come up when an API platform is scoped for testing.
Should the tester be allowlisted through the gateway?
Usually yes for the application testing, so days are not lost fighting rate limits. Run a short unallowlisted phase as well, because the protections themselves are worth assessing.
Does mutual TLS solve the direct access problem?
It solves it well when every caller must present a certificate the service verifies. The common failure is enforcing it at the gateway and leaving the service accepting plain connections from inside the network.
