Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
An API gateway sits in front of a fleet of backend services and centralizes cross-cutting concerns — authentication, authorization offload, rate limiting, request/response transformation, and schema validation — so individual services do not each reimplement them. Done well, this consolidates security enforcement into one well-tested, well-monitored choke point; done poorly, it creates a false sense of security if backend services silently trust whatever the gateway forwards without any verification of their own.
The security value of a gateway depends entirely on whether it is actually the *only* path to the backend, and whether the trust it establishes (an authenticated user’s identity, say) is communicated to backend services in a way they can verify rather than a header they simply believe. A gateway that authenticates perfectly but sits in parallel with a directly reachable backend, or whose trust headers a client can forge by connecting to the backend directly, provides little real protection.
Attack Prerequisites
Exploiting a gateway-fronted architecture generally requires one of:
- Direct network access to a backend service, bypassing the gateway entirely — possible when network segmentation does not actually restrict backend ingress to gateway traffic only.
- A backend that trusts gateway-injected headers without verification — e.g.
X-User-IdorX-Auth-Scopeset by the gateway after authentication, but not stripped from client requests that reach the backend by another path, or not stripped from requests that reach the gateway itself with the header pre-set. - Inconsistent authorization between gateway and backend — the gateway checks coarse-grained access (is this a valid token?) while fine-grained, resource-level authorization is assumed, but never actually performed, by the backend.
- Weak or missing schema validation at the edge — the gateway passes through malformed or oversized payloads that a backend service does not defensively validate itself.
How It Works
A gateway typically terminates TLS from the client, validates a bearer token or API key (JWT validation against a JWKS endpoint, OAuth introspection, or a static API key lookup), applies rate limiting and quota policy per client, and routes the request to the appropriate backend — often over a separate, internal network segment using mutual TLS so backends can cryptographically verify traffic actually originated from the gateway rather than an arbitrary internal host. Along the way it commonly injects identity context (subject, scopes, tenant ID) as headers so backends do not each need to parse the token themselves.
This pattern — the gateway does the expensive validation once, backends trust its output — is efficient, but it creates a trust boundary that has to be enforced structurally, not just by convention: the backend must be unreachable except through the gateway (network policy, mTLS-only listeners), and the gateway must strip any client-supplied header that collides with its own trust-header names before injecting its own, so a client cannot simply set X-User-Id: admin and have it survive to the backend.
Schema validation (typically driven from an OpenAPI/JSON Schema definition loaded into the gateway) rejects malformed requests before they reach application code, reducing the backend’s exposure to injection and deserialization bugs — but only for the fields the schema actually constrains; an overly permissive schema (free-form additionalProperties: true objects) provides little real protection.
Practical Example / Configuration
An Envoy jwt_authn filter validating a bearer token against a JWKS endpoint before forwarding to the backend cluster — this establishes authentication at the edge, but note it says nothing about authorization or header hygiene:
http_filters:
- name: envoy.filters.http.jwt_authn
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
providers:
idp_provider:
issuer: https://idp.example/
audiences: ["orders-api"]
remote_jwks:
http_uri:
uri: https://idp.example/.well-known/jwks.json
cluster: idp_jwks
timeout: 5s
rules:
- match: { prefix: "/" }
requires: { provider_name: "idp_provider" }
The trust-boundary bug this misses: without an explicit rule to strip client-supplied identity headers before the gateway injects its own, a client that already knows the header name the backend trusts can smuggle it through unauthenticated paths or via a gateway misconfiguration. The fix is explicit at the gateway edge:
# Strip any client-supplied trust headers before authenticating,
# THEN inject the verified identity -- order matters.
request_headers_to_remove:
- x-user-id
- x-auth-scope
# ... jwt_authn filter runs, then a header-injection rule adds
# x-user-id / x-auth-scope from the verified JWT claims, never from
# the original client request.
Walkthrough / Exploitation
Assessing a gateway-fronted API starts with mapping whether the backend is reachable on any path other than through the gateway:
# Enumerate backend hostnames/IPs from DNS, cloud metadata, or
# service discovery, then test direct reachability bypassing the
# gateway's hostname entirely:
curl -k https://orders-internal.svc.cluster.local:8443/orders/1
Next, test whether identity/trust headers set by the gateway can be forged by a client that reaches the gateway (or, worse, the backend directly):
curl https://api.example/orders/1 \
-H "Authorization: Bearer <low-priv-token>" \
-H "X-User-Id: admin" \
-H "X-Auth-Scope: orders:admin"
# If the response reflects admin-level access, the backend trusted
# a client-supplied header instead of one the gateway verified.
Finally, probe for inconsistent authorization: a token valid for one tenant/resource accepted by the gateway (correct audience) but not re-checked for object-level ownership by the backend — this maps directly to OWASP API Security Top 10’s API1:2023 Broken Object Level Authorization, the most common real-world API finding.
Note: Gateway sprawl — multiple gateways deployed by different teams with inconsistent policy, or “shadow” APIs deployed without ever being registered behind the gateway at all — is a more common root cause of exposure than a flaw in the gateway product itself. Maintaining an accurate inventory of what is (and is not) fronted is a prerequisite for the gateway’s controls to mean anything.
Opsec: When testing for direct backend access during an authorized assessment, treat any successful direct connection as a finding regardless of whether you can further exploit it — reachability alone means the gateway’s controls are not actually mandatory.
Detection and Defense
- Enforce network policy so backends are only reachable from the gateway (Kubernetes NetworkPolicy, security groups, or a service mesh with mTLS-only listeners) rather than relying on “nobody knows the internal hostname.”
- Strip client-supplied trust headers at the edge before authenticating, and inject identity headers only after verification, so there is no path for a client value to survive.
- Re-verify object-level authorization at the backend, not just coarse authentication at the gateway — the gateway proves who the caller is, not what they are allowed to touch.
- Validate request schemas strictly (reject unknown fields, enforce types/lengths) from an OpenAPI definition kept in sync with the actual backend contract.
- Correlate requests end-to-end with a gateway-issued request/trace ID logged at both gateway and backend, so an investigation can reconstruct the full path of a suspicious call.
Real-World Impact
OWASP’s API Security Top 10 has ranked Broken Object Level Authorization as the most prevalent API vulnerability class across successive editions, and it recurs specifically because gateways are good at authentication but organizations frequently assume that implies authorization is handled too. As API surface area grows through gateway consolidation, a single misconfigured trust header or an unregistered backend path has an outsized blast radius compared to a bug in one standalone service.
Conclusion
An API gateway is a strong, centralizing security control only when backends cannot be reached any other way and only trust headers the gateway itself verified — everything else it does (rate limiting, schema validation, logging) is valuable but secondary to enforcing that trust boundary structurally rather than by convention.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments