API Gateway Security Guide: Authentication, Rate Limits and Policy Enforcement

An API gateway is only a security control if it is configured to reject bad requests, and many are deployed as routing layers that pass almost everything through. Gateways sit at the point where every API call can be authenticated, checked against policy, rate limited and logged, which makes them the most efficient place to enforce consistent controls across dozens or hundreds of services. They are also a single point of failure: a permissive default, a fail-open authoriser or an unregistered route bypasses every backend that relies on it. This guide covers what a gateway should and should not enforce, authentication patterns, token validation settings, rate limiting, policy enforcement, the gateway's own credentials, and how to roll changes out safely. It is for platform engineers, API owners and security architects. For API risks in general see the API Security Guide; this page focuses on the gateway layer.

Key takeaways

• Enforce authentication at the gateway, authorisation at both layers. The gateway can verify who is calling and coarse scopes, but object level checks (OWASP API1:2023) need data the backend holds.
• Validate tokens strictly. Pin issuer and audience, require signatures and expiry, allow only expected algorithms, and keep clock skew small.
• API keys identify and meter; they do not authenticate a user. Use OAuth 2.0 tokens, mTLS or signed requests for authentication and keep keys for usage plans and quotas.
• Fail closed. If an external authoriser or JWKS endpoint is unreachable, the safe outcome is a rejected request, and that setting must be checked explicitly.
• Close the bypass. Backends must accept traffic only from the gateway, otherwise every gateway policy is optional for an attacker who finds the origin.

What a gateway should enforce, and what it cannot

NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems (final, updated March 2026 with appendices listing API risks and recommended controls by lifecycle stage), separates pre-runtime controls from runtime controls. The gateway is the main runtime enforcement point, but not the only one.

Gateway types differ: cloud managed gateways (Amazon API Gateway, Azure API Management, Google Apigee), self-hosted gateways built on proxies such as Envoy, NGINX or Kong, and service mesh ingress for east-west traffic. The controls below apply to all of them; the setting names differ. For AI and model traffic specifically see the AI Gateway and LLM Gateway Guide.

Authentication patterns at the gateway

Amazon API Gateway illustrates the split: resource policies, IAM, Lambda authorisers and Amazon Cognito user pools control who can invoke a method, while usage plans and API keys track and limit usage for access already granted. Treat that as the general rule. The API Key Management Guide covers key issuance and rotation.

Token validation settings that matter

Most gateway token bypasses come from validation that is present but loose. Using Azure API Management's validate-jwt policy as a concrete example, check these settings on every route:

• Issuer: the issuers list must contain only your authorisation server(s). Accepting any issuer whose keys validate allows tokens from other tenants of a shared identity provider.
• Audience: audiences must name this API. Without an audience check, a token issued for a different API in the same tenant is accepted.
• Signature: require-signed-tokens defaults to true; keep it. Restrict accepted algorithms to the ones your issuer uses and never accept none. See the JWT Security Guide.
• Expiry: require-expiration-time defaults to true; keep it, and keep access token lifetimes short at the issuer.
• Clock skew: clock-skew defaults to 0 seconds. A small allowance (Microsoft's example uses 60) avoids spurious failures; minutes of skew extend stolen token life.
• Keys: fetch signing keys from openid-config rather than pasting static keys, so issuer key rotation does not break or weaken validation. API Management caches the JWKS for an hour and refetches at most every five minutes when a kid is unknown.
• Required claims: use required-claims to enforce scopes or roles per operation, which is where function level authorisation lives at the gateway.
• Failure response: return 401 for missing or invalid tokens and 403 for valid tokens lacking scope, with generic error messages.

Pass the validated identity to the backend in a header that the gateway always overwrites, and strip any client supplied copy of that header. A backend that trusts X-User-Id from any source is an authentication bypass.

Rate limiting, quotas and resource limits

Gateways usually implement rate limiting with a token bucket: a steady rate at which capacity refills and a burst size. Amazon API Gateway applies throttles in order: per client or per method limits in a usage plan, per method limits on a stage, account level limits per Region, then AWS Regional limits, and returns 429 Too Many Requests when exceeded. AWS states that throttles and quotas are applied on a best effort basis and should be treated as targets rather than guaranteed ceilings, which is a reason not to rely on gateway throttling alone for cost or abuse control.

Do not key limits on source IP alone: attackers rotate addresses and many legitimate users share NAT. Combine IP with authenticated identity. Sensitive business flows (OWASP API6:2023) such as checkout or account creation need business limits as well as rate limits. The Rate Limiting and API Abuse Guide covers algorithms and abuse patterns in depth.

Policy enforcement and external authorisation

• Default deny routes: configure the gateway so unknown paths return 404 rather than proxying to a backend with a wildcard route. Every exposed route should exist in an OpenAPI or equivalent specification.
• Schema validation: validate request bodies, parameters and content types against the specification and reject unknown fields where the API design allows.
• External authorisers fail closed: Envoy's ext_authz filter returns 403 when the authorisation service denies a request. Its failure_mode_allow setting, when true, lets requests through if the authorisation call itself errors; keep it false for anything sensitive and monitor the failure_mode_allowed counter. Envoy's documentation also warns that per-route ext_authz settings can be bypassed if a later filter clears the route cache, so review filter order.
• Decision caching: custom authoriser results are often cached by token. Keep cache lifetimes shorter than your revocation expectations.
• Policy as code: keep gateway configuration in version control with review, and test policies in CI against known good and known bad requests.
• Edge layering: a WAF in front of or inside the gateway handles injection signatures and bot patterns; the gateway handles identity and contract. See the Web Application Firewall Guide.

Where identity fits: the gateway's own credentials

A gateway is a non-human identity with significant reach. It holds TLS private keys, client certificates for backend mTLS, credentials to call the authorisation server for introspection, and often API keys or OAuth client secrets for upstream third party APIs it proxies. Its management plane can rewrite every route.

• Management plane: restrict who can change gateway configuration, require MFA for console access and use CI deployment identities with workload identity federation rather than stored admin keys.
• Upstream secrets: store them in a secrets manager referenced by the gateway (Azure API Management named values backed by Key Vault, for example) rather than inline in policy files.
• Backend trust: lock backends to the gateway with private networking, mTLS or a signed gateway credential, so the origin cannot be called directly.
• Client credential lifecycle: every API consumer is itself a non-human identity. Track owners, scopes and last use of every client registered at the gateway and remove unused ones. See the Secrets Management Guide.

Implementation approach

1. Inventory: export all routes, authentication settings and plugins from every gateway and compare against API specifications and backend service lists. Flag unauthenticated routes and routes with no owner.
2. Baseline policy: define a standard policy set (TLS minimum version, token validation with issuer and audience, default rate limit, body size limit, logging fields) applied to every route by default, with documented exceptions.
3. Audit mode first: where the gateway supports it, log validation failures without blocking for one to two weeks. Use the logs to find clients sending malformed tokens or exceeding limits.
4. Pilot ring: enforce on one non-critical API, then on internal consumers, then partners, then public traffic. Communicate rate limits and error formats to API consumers before enforcement.
5. Close the bypass: restrict backends to gateway traffic only, then scan for directly reachable origins.
6. Rollback: deploy policies through versioned configuration so a bad change can be reverted to the previous revision in one step, and keep per-route overrides so one failing client does not force a global rollback.

Decision guidance

• Managed vs self-hosted gateway: managed gateways reduce patching and give built in integrations with cloud IAM; self-hosted gateways give finer control, portability and private deployment. Many organisations run a managed edge gateway for external traffic and a mesh or self-hosted gateway internally.
• JWT vs introspection: local JWT validation is fast and resilient; introspection supports immediate revocation. Use short-lived JWTs for most traffic and introspection for high risk operations.
• mTLS vs OAuth for machine clients: mTLS gives strong proof of possession for a small number of known partners; OAuth client credentials scale better to many clients. They can be combined with certificate-bound tokens. See the OAuth 2.1, GNAP and FAPI Guide.
• Small organisations: one managed gateway with standard policies and logging, with token validation against a single identity provider, is sufficient.
• Large organisations: centralise policy definitions, delegate route ownership to API teams, and enforce baseline policy through CI checks on gateway configuration.

Detection and measurement

Log for every request: client ID, token subject, route, status code, latency, request size, response size and the policy decision. Send gateway logs to the SIEM and alert on spikes in 401 and 403 responses per client, a single client reading many distinct object IDs, sudden growth in response bytes, authoriser errors or fail-open events, and configuration changes outside change windows.

Framework mapping

In D3FEND terms, gateway filtering is a form of Inbound Traffic Filtering (D3-ITF) and request logging feeds Network Traffic Analysis (D3-NTA). In CIS Controls v8.1 the gateway supports Control 6 (Access Control Management), Control 8 (Audit Log Management), Control 13 (Network Monitoring and Defense) and Control 16 (Application Software Security). In ISO/IEC 27001:2022 Annex A the closest controls are A.8.5 Secure authentication, A.8.15 Logging, A.8.20 Networks security and A.8.26 Application security requirements.

Common failure patterns

• Origin reachable directly: backends on public IPs or shared networks accept requests that never touched the gateway, so authentication and rate limits are skipped.
• Token accepted without audience check: any valid token from the shared identity provider works on every API.
• API keys treated as authentication: static keys embedded in mobile apps or front end code become the only barrier to customer data.
• Fail-open authoriser: failure_mode_allow or an equivalent setting left on, so an outage in the authorisation service opens the API.
• Forgotten routes and versions: old API versions left routed through the gateway with weaker policies, a classic API9:2023 inventory gap.
• No per-client volume alerting: a valid client pulling records slowly for weeks goes unnoticed, as in the case below.

Lessons from incidents

In the T-Mobile API Breach, an attacker accessed a customer data API without authorisation from around 25 November 2022 until detection on 5 January 2023, retrieving records for about 37 million accounts. T-Mobile has not disclosed how authentication or authorisation was bypassed, so the specific gateway failure is unknown. What the incident does show is the value of gateway-level controls that are within the operator's reach: per-client volume limits and quotas on bulk record retrieval, alerting on abnormal response volume per client, and an inventory that includes internal and legacy APIs. Six weeks of undetected extraction is a measurement failure as much as an access failure.

Practitioner checklist

• Export every gateway route and confirm each has an owner, a specification and an authentication policy.
• Enforce issuer, audience, signature, algorithm allow list and expiry checks on every token validating route.
• Use API keys only for client identification and quotas, never as the sole authentication for sensitive data.
• Set external authorisers to fail closed and alert on any fail-open event.
• Overwrite identity headers at the gateway and strip client supplied copies.
• Restrict every backend to accept traffic only from the gateway.
• Apply per client, per user and per route rate limits, quotas and body size limits.
• Keep gateway configuration in version control with review and one step rollback.
• Store upstream secrets and TLS keys in a secrets manager and govern management plane access.
• Stream gateway logs to the SIEM and alert on per-client volume anomalies and 401/403 spikes.

Standards and references

• NIST: SP 800-228 Guidelines for API Protection for Cloud-Native Systems
• OWASP: API Security Top 10 2023
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
• Microsoft Learn: Azure API Management validate-jwt policy
• AWS: Controlling and managing access to REST APIs in API Gateway
• AWS: Throttle requests to your REST APIs
• Envoy: External Authorization filter

Related NHI Mgmt Group resources: API Security Guide, Rate Limiting and API Abuse Guide, Load Balancer Security Guide, Proxies and Forward vs Reverse Proxy Security Guide, Secure API Design Guide.