Teams often put an API behind a web application firewall or an API gateway and assume the API is protected, when each one covers only part of the API risk list. A WAF inspects HTTP traffic for attack patterns; an API gateway knows what each API is, who is calling it and how often. This guide compares what each control does, maps the OWASP API Security Top 10 2023 to the layer that can actually enforce it, and sets out deployment patterns, rollout steps and metrics. It is for platform, API and security engineers deciding where to place controls in front of internal and public APIs.
Key takeaways
- A WAF protects against malicious payloads. It applies rules to the HTTP conversation, such as SQL injection and cross-site scripting signatures, mostly without knowing the API's business meaning.
- An API gateway enforces the API contract and the caller. It routes, authenticates, applies quotas and rate limits, validates against a schema and records who called what.
- Neither fixes object-level authorisation. Broken object level authorisation (API1:2023) has to be enforced in the application or service, because only it knows who owns which record.
- Most internet-facing APIs need both. Put the WAF (and DDoS protection) at the edge, the gateway behind it, and authorisation in the service.
- Configuration matters more than product. A WAF left in detection-only mode or a gateway that passes unauthenticated routes gives a false sense of coverage.
What each one is
A web application firewall (WAF) is, in OWASP's description, an application firewall for HTTP applications that applies a set of rules to an HTTP conversation, generally to detect attacks such as cross-site scripting and SQL injection. It is often deployed as a reverse proxy in front of applications, at a CDN edge or as a module in the web server. Many WAFs use rule sets such as the OWASP CRS, a free and open source collection of generic attack detection rules for ModSecurity-compatible engines.
An API gateway is a reverse proxy dedicated to APIs. It terminates client connections, routes requests to backend services, validates credentials (API keys, OAuth 2.0 access tokens, JWTs or client certificates), applies per-consumer quotas and rate limits, transforms requests, can validate payloads against an OpenAPI schema, and produces per-consumer logs. See the API Gateway Security Guide for hardening the gateway itself.
The two are converging: many WAF products now offer API schema validation and rate limiting, and many gateways offer basic threat protection. The comparison below is about the control functions, whichever product hosts them.
Side-by-side comparison
| Dimension | WAF | API gateway |
|---|---|---|
| Primary purpose | Block malicious HTTP requests | Publish, route and govern APIs |
| Decision basis | Attack signatures, anomaly scores, IP reputation, request properties | Identity of the caller, API definition, plan or quota, route policy |
| Knows the caller | Usually by IP, headers or session only | Yes: consumer, application, client ID or certificate |
| Knows the API contract | Only if a schema is loaded | Yes: routes, methods, versions, often an OpenAPI definition |
| Authentication | Not its role | Validates keys, tokens and certificates |
| Rate limiting | Per IP or per path | Per consumer, per plan, per route |
| Typical placement | Edge, CDN or in front of the load balancer | Behind the edge, in front of services; sometimes per domain or team |
| Main tuning effort | False positives and rule exclusions | Policy per API, consumer onboarding, credential lifecycle |
| Main failure | Detection-only mode left on; JSON bodies not inspected | Routes published without auth; shadow APIs bypassing it |
Which layer handles each OWASP API risk
The OWASP API Security Top 10 2023 is a good test of placement. The table shows the layer that can enforce each risk; "supporting" means the layer helps but cannot solve it alone.
| OWASP API risk (2023) | WAF | API gateway | Application or service |
|---|---|---|---|
| API1 Broken Object Level Authorization | No | No | Primary: check ownership of every object |
| API2 Broken Authentication | Supporting: credential stuffing and brute force signals | Primary: token and key validation | Primary for login and session logic |
| API3 Broken Object Property Level Authorization | No | Supporting: response schema filtering | Primary |
| API4 Unrestricted Resource Consumption | Supporting: per-IP limits and DDoS | Primary: per-consumer quotas, payload size limits, timeouts | Pagination and query limits |
| API5 Broken Function Level Authorization | No | Supporting: scope or role checks per route | Primary |
| API6 Unrestricted Access to Sensitive Business Flows | Supporting: bot signals | Supporting: per-consumer limits | Primary, with bot management |
| API7 Server Side Request Forgery | Supporting: URL pattern rules | No | Primary: allow-list outbound destinations |
| API8 Security Misconfiguration | Supporting: header and method rules | Primary: TLS, CORS, method restrictions | Primary |
| API9 Improper Inventory Management | No | Primary: the gateway catalogue is the inventory, if all traffic passes it | Supporting |
| API10 Unsafe Consumption of APIs | No | Supporting for egress gateways | Primary: validate third-party responses |
The pattern is clear: the WAF is strongest on payload attacks and volumetric abuse, the gateway on identity, quotas and inventory, and authorisation stays in the code. See the API Security Guide for application-side controls.
When to use a WAF, an API gateway or both
- WAF alone: a traditional web application with server-rendered pages and few or no public APIs, or a legacy API you cannot change and need to shield quickly (virtual patching).
- Gateway alone: internal service-to-service APIs on a private network where callers are known workloads, traffic is authenticated with mTLS or tokens, and there is no internet exposure.
- Both: any public or partner API. The edge WAF absorbs scanning, injection attempts and floods; the gateway authenticates consumers and enforces quotas.
- Small organisations: a managed WAF at the CDN plus the gateway features of your cloud platform usually cover the layers without extra infrastructure.
- Large organisations: standardise one edge WAF policy, run gateways per domain or business unit, and require every API to be registered in the gateway catalogue before it receives a public route.
Each option in depth
For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.
Web application firewall
Threat model. The WAF is built for an attacker who sends crafted HTTP requests: injection strings, cross-site scripting payloads, path traversal, protocol abuse and automated scanning against a public-facing application (T1190). It assumes the attacker is anonymous or only weakly identified, so its decisions rest on what the request looks like rather than on who sent it. It is weak against an attacker who holds a valid credential and sends well-formed requests, because nothing in the payload looks malicious.
Failure modes. The OWASP CRS uses anomaly scoring: each matching rule adds to a score (5 for a critical match, 4 error, 3 warning, 2 notice) and the request is blocked when the inbound score reaches the threshold, 5 by default, or 4 for outbound responses. CRS documentation warns that raising thresholds above the defaults for longer than a tuning period lets many attacks through, and that some products ship higher default thresholds, which it treats as an improper implementation that causes bypasses. Early blocking, which is off by default, saves resources but means early-blocked requests never have their bodies inspected, so logs hold less detail. The other common failure is simply not parsing JSON, so API payloads are never scored.
Controls. Run the CRS at its default thresholds once tuned; CRS suggests a new deployment can start in blocking mode with very high thresholds and lower them gradually, rather than living in detection-only mode. Write narrow exclusions per route and parameter, never global ones. Confirm JSON and, where used, GraphQL bodies are parsed. Pair the WAF with DDoS protection at the edge, and send its logs with the same request ID the gateway uses.
Decision criteria. Choose the WAF as the primary control when the risk is payload attacks on code you cannot change quickly (virtual patching), when callers are anonymous, or when the asset is a server-rendered web application rather than an API. It is a supporting control, never the answer, for authentication, quotas and authorisation.
Worked scenario. A retailer finds an injection flaw in a legacy order-status endpoint that will take a month to fix. The team adds a WAF rule exclusion review for that route, confirms the WAF parses the JSON body, and lowers a temporarily raised inbound threshold back to 5 for that path. Scanner traffic hitting the endpoint is now blocked at the edge, while the code fix is scheduled. The WAF has bought time; it has not fixed the flaw, and the ticket stays open until the patch ships.
API gateway
Threat model. The gateway is built for a caller who is known or should be: a partner integration, mobile back end, script or AI agent holding an API key, OAuth client credential, token or certificate. Its threats are stolen or shared credentials, abuse within a valid credential (scraping, enumeration, resource exhaustion under API4:2023), shadow and old API versions outside its catalogue (API9:2023), and backends that can be reached without passing through it. NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems, frames API controls in pre-runtime and runtime stages and compares ways of implementing them, which is the right lens: the gateway is a runtime enforcement point, but its catalogue depends on pre-runtime inventory.
Failure modes. Routes published without authentication; one credential shared by several consumers so abuse cannot be attributed; keys that never expire; per-IP limits only; schema validation switched off because it broke a client; and, most damaging, backends still reachable directly so every gateway policy is optional.
Controls. Require authentication on every route and one credential per consumer with an owner. Prefer short-lived OAuth tokens or mTLS for machine callers. Set per-consumer quotas, payload size limits and timeouts. Validate requests against the OpenAPI definition. Lock backends to accept traffic only from the gateway. Manage policy as version-controlled configuration with canary deployment and rollback.
Decision criteria. Choose the gateway as the primary control whenever callers are identifiable and the API has a contract: partner, mobile and internal service APIs. It is the place to measure inventory coverage and to revoke a single consumer without affecting others.
Worked scenario. A partner key is seen pulling far more records than the partner's contract implies. Because each partner has its own credential, the gateway shows exactly which consumer, which routes and which hours. The team cuts that consumer's quota, rotates its key, and asks the partner to confirm whether the traffic was theirs. The WAF saw nothing unusual, because every request was well formed. Separately, the object-level check in the service confirms the records returned all belonged to that partner, which is the control that actually limits the damage.
Where identity fits
Most API callers are non-human: partner integrations, mobile back ends, scripts and AI agents using API keys, OAuth client credentials or certificates. The gateway is where those identities are checked, so it is also where weak practice shows up: long-lived static keys, shared keys across consumers, and no owner per key. Prefer short-lived OAuth tokens or mTLS for machine clients, issue one credential per consumer, and review gateway keys and usage plans regularly. See How to audit API gateway keys and usage plans and the API Keys vs OAuth Tokens Guide.
How to deploy the two together
- Inventory first. List every API host and route, including old versions. Anything not behind the gateway is a candidate shadow API (API9:2023).
- Place the WAF at the edge in detection mode. With the OWASP CRS, start at paranoia level 1 (the baseline for internet-facing servers) and the default anomaly scoring thresholds (inbound 5, outbound 4). Confirm the WAF parses JSON request bodies for API routes.
- Tune, then block. Review matches for one to two weeks, write narrow rule exclusions for confirmed false positives, then switch to blocking. Raise paranoia levels only for high-risk routes, because CRS warns that higher levels bring more false positives.
- Route all API traffic through the gateway. Lock backends so they accept traffic only from the gateway (network policy, private endpoints or mTLS), otherwise the gateway can be bypassed.
- Apply gateway policies per API. Require authentication on every route, set per-consumer quotas and payload size limits, and enable request validation against the OpenAPI definition.
- Keep authorisation in services. Add object-level checks in code and test them; do not rely on the gateway to infer ownership.
- Roll back safely. Change WAF rules and gateway policies through version-controlled configuration, deploy to a canary route first, and revert to the previous policy version if error rates rise.
Detection and measurement
- Gateway coverage: share of known API routes served through the gateway, and count of API hosts found outside it.
- Authentication coverage: share of gateway routes that require authentication.
- WAF blocking mode: share of applications and APIs where the WAF blocks rather than only logs.
- False positive rate: confirmed false positives per million requests, tracked after each rule change.
- Quota breaches: consumers repeatedly hitting rate limits, a signal of abuse or a misbehaving integration.
- Correlated logging: share of requests where WAF, gateway and service logs share a request ID, so an incident can be traced end to end.
Common failure patterns
- Bypassable gateway. Backends remain reachable directly by IP or an old hostname, so all gateway policy is optional for an attacker.
- WAF in permanent detection mode. Rules were never tuned, so blocking was never switched on.
- Uninspected JSON. The WAF inspects form posts but not JSON or GraphQL bodies, which is where API payloads travel.
- Expecting the WAF to stop BOLA. Requests changing an object ID are syntactically valid and pass every signature.
- Per-IP limits only. Distributed abuse from many addresses stays under each limit; per-consumer quotas at the gateway are needed.
- Old API versions left published. A deprecated version without current policies stays live and reachable.
Framework mapping
| Framework | Reference | WAF | API gateway |
|---|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-7 Boundary Protection | Primary | Primary |
| NIST SP 800-53 Rev. 5 | SI-10 Information Input Validation | Supporting | Schema validation |
| NIST SP 800-53 Rev. 5 | SC-5 Denial-of-service Protection | Primary | Quotas and limits |
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication, AC-3 Access Enforcement | No | Primary |
| NIST CSF 2.0 | PR.IR-01, PR.AA-05, DE.CM-01 | Network protection and monitoring | Access enforcement and monitoring |
| MITRE ATT&CK | T1190 Exploit Public-Facing Application, T1499.003 Application Exhaustion Flood, T1110 Brute Force | Detect and block | Rate limit and authenticate |
NIST SP 800-228, Guidelines for API Protection for Cloud-Native Systems (final, updated 13 March 2026 with appendices on API risks and controls by lifecycle stage), is the most specific NIST reference for API controls.
Practitioner checklist
- Inventory every API route and confirm each is served through the gateway.
- Block direct access to backends so the gateway cannot be bypassed.
- Require authentication on every gateway route and one credential per consumer.
- Set per-consumer quotas, payload size limits and timeouts.
- Validate requests against the OpenAPI definition at the gateway.
- Run the edge WAF with JSON body inspection and move it to blocking after tuning.
- Keep object and function level authorisation in the service, with tests.
- Correlate WAF, gateway and service logs with a shared request ID.
- Retire old API versions from both WAF and gateway configuration.
Standards and references
- OWASP: API Security Top 10 2023
- NIST: SP 800-228 Guidelines for API Protection for Cloud-Native Systems
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- OWASP: Web Application Firewall
- OWASP CRS: Documentation
- OWASP CRS: Anomaly Scoring
- OWASP CRS: Paranoia Levels
- MITRE ATT&CK: Exploit Public-Facing Application
Related NHI Mgmt Group resources: API Security Guide · API Gateway Security Guide · Bot Management Guide · DDoS Protection Guide