A compromised API gateway gives an attacker the one place where every API key, token signing trust, upstream credential and routing rule for your APIs comes together, so the response has to treat the gateway as an identity breach, not just a host breach. The gateway validates consumer keys and tokens, holds the credentials it uses to call upstream services, terminates TLS and decides which requests reach which backend. Whoever controls it can mint access, read decrypted traffic, reroute calls and switch off rate limits and authorisation checks while the dashboard still looks normal. This playbook is for API platform, application security and incident response teams. It is vendor-neutral and applies to self-hosted gateways, managed cloud gateways and gateways built into an ingress or service mesh: confirm exact settings in your product's documentation. Preventive controls are in the API Gateway Security Guide, which this page does not repeat.
Key takeaways
- Treat the gateway as a credential store. Consumer API keys, client secrets, upstream service credentials, TLS private keys and token validation trust all have to be rotated, in an order that keeps critical APIs running.
- Restore authorisation before availability. An attacker who disabled authentication plugins, widened routes or removed rate limits leaves you exposed even after they lose access; rebuild configuration from version control, not from the running gateway.
- Cut the gateway's own identities early. Its admin API tokens, cloud role, service account and deployment pipeline credentials are often more valuable than any single API key it holds.
- Make backends stop trusting the old gateway. Backends that accept any request from the gateway's network address or a shared header are reachable by anyone who holds that trust; replace it with new mutual TLS certificates or signed tokens.
- Revocation does not reach every token. Self-contained access tokens stay valid until they expire unless resource servers check revocation, so shorten lifetimes and rotate signing keys where forged or stolen tokens are possible.
What an attacker gains from a gateway
The table shows the exposure by gateway component. A real deployment usually combines several, and the planning question is which of them the attacker reached.
| Component reached | What the attacker gains | Response lever |
|---|---|---|
| Admin API or management console | Create consumers and keys, change routes, disable authentication and rate limiting plugins, add log sinks, export configuration including stored secrets | Revoke admin tokens, lock the admin plane to a break-glass account, rebuild configuration from source |
| Data plane node or container | Decrypted traffic (bearer tokens, cookies, personal data), in-memory secrets, the node's cloud role or service account | Drain and replace nodes from a clean image, revoke host identity sessions |
| Configuration store or database | Consumer credentials (hashed or plaintext depending on product), upstream credentials, plugin secrets, TLS keys if stored there | Rotate everything stored, check whether keys were hashed |
| Token validation trust | If the attacker can change the trusted issuer or JSON Web Key Set (JWKS) URL, tokens they sign are accepted | Reset issuer and JWKS configuration, review all tokens accepted in the window |
| Deployment pipeline (declarative config, GitOps) | Persistence: weakened policy is redeployed after cleanup | Rotate pipeline credentials, review commits and merge rights |
| Developer portal | Self-service key issuance, changes to plans and quotas, consumer contact data | Freeze self-service registration, review new applications and keys |
How the compromise shows up
- Exploited management plane: an advisory or a CISA Known Exploited Vulnerabilities entry for your gateway version, unknown admin users, or admin API calls from addresses outside your management network (ATT&CK T1190 Exploit Public-Facing Application).
- Authentication quietly removed: routes with the authentication plugin disabled, an anonymous consumer added, a route matching a wider path than before, or authorisation checks moved from enforce to log only. These are the gateway form of OWASP API Security Top 10 2023 API2 Broken Authentication and API5 Broken Function Level Authorization.
- Rate limits and quotas removed: sudden traffic growth on expensive endpoints or bulk data endpoints that used to be throttled (API4 Unrestricted Resource Consumption).
- New consumers or keys: applications or keys created outside your onboarding process, especially with broad plans, or keys added to existing consumers (ATT&CK T1098.001 Additional Cloud Credentials where the gateway is a managed cloud service).
- Traffic diversion and mirroring: upstream targets changed to unknown hosts, a traffic mirroring or request logging plugin sending full bodies to an external endpoint (ATT&CK T1557 Adversary-in-the-Middle).
- Token trust changed: a new issuer, JWKS URL or shared signing secret in the JWT validation configuration, or tokens accepted with unexpected issuers or key IDs (
kid). - Use of the gateway's identities elsewhere: its cloud role, service account or upstream client credentials used from addresses that are not gateway nodes (ATT&CK T1078.004 Cloud Accounts, T1550.001 Application Access Token).
Triage: the first hour
- Establish the entry point: admin plane, data plane node, configuration store, pipeline, developer portal, or a stolen admin credential. The answer decides how much has to be rotated.
- Export and freeze evidence before changing anything: running configuration, admin audit log, access logs, plugin configuration and node images or snapshots.
- Diff the running configuration against version control. List every route, consumer, credential, plugin and upstream that differs. This list is your initial scope of attacker changes.
- Inventory the credentials the gateway holds: consumer keys and secrets, upstream credentials, mutual TLS client certificates, TLS server keys, signing secrets, admin tokens, cloud role and pipeline credentials. Note for each whether the gateway stores it hashed, encrypted or in plaintext.
- Rank the APIs behind the gateway by data sensitivity and business impact. Containment and rotation follow that ranking.
- Decide the safe path for critical APIs: a standby gateway built from source control, a separate cluster, or temporary restriction to known consumers.
Containment by priority
- Close the admin plane. Revoke all admin API tokens and sessions, disable unknown admin accounts, restrict the admin interface to a management network or bastion, and keep a single break-glass account for responders.
- Cut the gateway's own identities. Revoke sessions for the node cloud role or service account, rotate pipeline deploy credentials and remove the gateway's ability to read your secrets manager until it is rebuilt. If nodes run on cloud instances, require the token-based instance metadata service on replacements.
- Move critical APIs to the safe path. Deploy a clean gateway from the last reviewed configuration and shift DNS or load balancer targets. Do not remove the gateway and expose backends directly to the internet.
- Re-anchor backend trust. Issue new mutual TLS client certificates or a new signing key for the clean gateway, then configure backends to reject the old certificate, old shared header value or old network range.
- Freeze self-service. Pause developer portal registration and key issuance until consumer records are reviewed.
Rollback: keep the previous routing documented so a critical API can be moved back if the clean gateway breaks a flow, but only to a path that does not run through compromised nodes or configuration.
Credentials to rotate, in order
| Order | Credential | Action | Why it matters |
|---|---|---|---|
| 1 | Admin API tokens, admin accounts, SSO trust for the console | Revoke, reset, re-establish SSO, require phishing-resistant MFA for admins | Stops the attacker changing the gateway again |
| 2 | Gateway cloud role, service account, pipeline credentials | Revoke sessions, issue new credentials, narrow permissions | The route from gateway to cloud data and to redeployment |
| 3 | Token validation trust (issuer, JWKS URL, shared HMAC secrets) | Reset to known values; if a signing secret was readable, rotate it at the issuer and publish a new key ID | Prevents tokens the attacker signs from being accepted |
| 4 | Upstream credentials (backend API keys, client secrets, mutual TLS client certificates) | Issue new ones at each backend, deploy to the clean gateway, then disable old ones | Lets the attacker call backends directly, bypassing the gateway |
| 5 | Consumer API keys and client secrets | Rotate in waves by consumer risk, with an overlap period for partners | Stored or observed keys let the attacker impersonate consumers |
| 6 | TLS server certificates and private keys | New keys, new certificates, revoke the old certificates citing key compromise | A copied key allows impersonation of your API hostnames |
| 7 | Tokens and sessions seen in decrypted traffic | Revoke refresh tokens at the authorisation server, shorten access token lifetime, invalidate sessions | Bearer tokens in traffic are usable until they expire |
| 8 | Log shipping and monitoring credentials | Rotate | Can be used to tamper with or flood logs |
For OAuth tokens, RFC 7009 notes that revoking a refresh token only invalidates related access tokens where the server supports access token revocation, and that self-contained tokens need non-standard backend interaction to revoke immediately; otherwise the remedy is short lifetimes. RFC 9700 recommends that access tokens be audience-restricted and sender-constrained, using mutual TLS (RFC 8705) or DPoP. A certificate-bound token carries a cnf claim with the certificate's x5t#S256 thumbprint, so a token copied from gateway traffic cannot be replayed without the client's private key. See the OAuth Token Introspection and Revocation Guide and, for consumer key waves, Credential Rotation at Scale.
Eradication and rebuild
- Replace, do not clean, data plane nodes. Rebuild from a clean, current image on a fixed release. Do not restore a configuration backup taken during the window.
- Rebuild configuration from version control. Re-apply the last reviewed declarative configuration, then review every route, consumer, plugin and upstream that existed only in the running gateway. Anything without an owner and a change record is removed.
- Check plugin and extension code. Custom plugins, scripts and serverless policy code can hold persistence. Compare them with the repository and rebuild them from source.
- Review the developer portal. Remove applications and keys created in the window, confirm plan and quota assignments, and check consumer contact details for changes that would redirect key reset emails.
- Hunt behind the gateway. Review backend logs for the window for requests that a weakened gateway let through: unauthenticated calls, object IDs walked in sequence, and bulk exports. Check whether upstream credentials were used from outside the gateway.
- Review accepted tokens. Search access logs for tokens with unexpected issuers, key IDs, audiences or very long lifetimes.
Recovery and return to service
- Run the clean gateway against regression tests for authentication, authorisation, rate limits and schema validation before it takes traffic.
- Move low-risk APIs first and watch error rates, latency and consumer complaints for a business cycle, unless critical APIs are still on a risky interim path, in which case move those first.
- Complete consumer rotation waves and disable old keys at the end of each overlap period. Track remaining old-key traffic to zero.
- Restore self-service only after consumer records are reviewed and admin access is limited to named, MFA-protected accounts.
- Decommission the old nodes and interim paths and delete temporary credentials.
Where identity fits
Most of the work in this playbook is non-human identity work: consumer keys, upstream client credentials, the gateway's own cloud role and pipeline tokens. Teams that already hold an inventory of these credentials, with owners and rotation paths, finish rotation in hours; teams that do not spend days finding them. Build that inventory before an incident using How to audit API gateway keys and usage plans, and handle individual leaked consumer keys with the API Key Leak Response Playbook.
Evidence and notification
- Preserve: node images or disk snapshots, admin audit logs, access logs, configuration exports with timestamps, plugin code, pipeline history and cloud audit logs for the gateway's identities.
- Personal data: gateway traffic often contains personal data and credentials. Under GDPR Article 33 the controller notifies the supervisory authority within 72 hours of becoming aware, where feasible, unless the breach is unlikely to result in a risk to individuals. See the Data Breach Notification Checklist and the Cyber Incident Reporting Requirements Map.
- API consumers: partners whose keys were stored or observed need to know, because they must deploy new keys and may need to check their own systems.
Decision guidance
| Situation | Choose | Trade-off |
|---|---|---|
| Admin credential misused, nodes untouched | Revoke admin access, restore configuration from source, rotate credentials readable through the admin API | Faster, but depends on a complete admin audit log |
| Data plane node or management plane exploited | Replace all nodes, rotate every credential the gateway holds, reissue TLS keys | Larger rotation workload against residual implant risk |
| Managed cloud gateway, tenant credentials stolen | Contain the cloud identities that manage the gateway, restore from infrastructure as code, rotate keys and usage plans | Provider audit logs decide how precisely you can scope |
| Consumer keys stored hashed | Rotate keys seen in traffic or created in the window first, others in planned waves | Less partner disruption, relies on knowing what was observed |
| Consumer keys stored in plaintext or reversible encryption | Rotate all consumer keys | Partner disruption, but anything less leaves usable keys |
| Small team, one gateway, no standby | Restrict critical APIs to known consumers while rebuilding | Some consumers lose access for the duration |
Detection and measurement
- Configuration drift: differences between the running gateway and version control, checked at least daily; target zero unexplained.
- Unauthenticated route count: routes without an authentication plugin that are not on an approved public list; target zero.
- Admin plane exposure: admin interfaces reachable from the internet; target zero.
- Time to safe path: minutes from declaration until critical APIs run on a clean gateway or are restricted.
- Rotation completion: share of gateway-held credentials rotated, tracked per credential class, and old-key traffic falling to zero.
- Direct backend access: requests reaching backends from outside the gateway's identity or network path.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| NIST CSF 2.0 | RS.MA-01, RS.AN-03, RS.MI-01, RS.MI-02, RC.RP-03, PR.AA-01 | Executing the plan, analysis, containment, eradication, verified restore assets, credential management |
| NIST SP 800-53 Rev. 5 | IR-4, IR-6, IA-5, AC-2, AC-6, SC-12, SC-23, CM-3, SI-4 | Incident handling and reporting, authenticators, accounts, least privilege, keys, session authenticity, change control, monitoring |
| CIS Controls v8.1 | Control 4, Control 5, Control 16, Control 17 | Secure configuration, account management, application software security, incident response |
| OWASP API Security Top 10 2023 | API2, API4, API5, API8 | Authentication, resource consumption, function level authorisation, security misconfiguration |
| MITRE ATT&CK | T1190, T1557, T1078.004, T1550.001, T1098.001 | Exploitation, interception, cloud accounts, application access tokens, added credentials |
Common failure patterns
- Restoring the running configuration. A backup from the window brings back the attacker's routes, anonymous consumers and disabled plugins.
- Rotating consumer keys but not upstream credentials. The attacker skips the gateway and calls backends with the gateway's own client secret or certificate.
- Leaving backends trusting a network range. Backends that accept anything from the gateway subnet are reachable by any compromised workload in it.
- Forgetting the token trust settings. An added issuer or JWKS URL survives node replacement if configuration is restored rather than rebuilt.
- Not looking for credentials in traffic logs. Request logging plugins that recorded headers hold bearer tokens and keys; the log store becomes a second exposure and needs purging or access restriction once evidence is preserved.
- Bypassing the gateway to restore service. Exposing backends directly removes authentication and rate limiting for exactly the APIs the attacker was targeting.
Practitioner checklist
- Keep the full gateway configuration in version control and alert on drift.
- Maintain an inventory of every credential the gateway holds, with owner and rotation path.
- Keep a tested standby gateway or a documented rebuild path for critical APIs.
- On compromise, close the admin plane and cut the gateway's own identities first.
- Reset issuer, JWKS and signing secret configuration to known values.
- Rotate upstream credentials and re-anchor backend trust to the clean gateway.
- Rotate consumer keys in waves by risk, tracking old-key traffic to zero.
- Reissue TLS keys and revoke tokens and sessions seen in traffic.
- Rebuild nodes from a clean image and configuration from reviewed source.
- Hunt behind the gateway for requests a weakened policy let through.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-204, Security Strategies for Microservices-based Application Systems
- OWASP: API Security Top 10 2023
- IETF: RFC 9700, Best Current Practice for OAuth 2.0 Security
- IETF: RFC 7009, OAuth 2.0 Token Revocation
- IETF: RFC 8705, OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
- CISA: Known Exploited Vulnerabilities Catalog
- MITRE ATT&CK: Adversary-in-the-Middle
Related NHI Mgmt Group resources: API Gateway Security Guide · API gateway health check · API Security Guide · OAuth Token Theft Incident Playbook · mTLS Guide