AWS WAF can block or count requests based on web ACL rules before traffic reaches protected AWS resources such as an Amazon API Gateway REST API. That is valuable, but it solves a different problem from determining whether an authenticated user is allowed to access a particular object, execute a business function, or perform an unusual sequence of otherwise valid API calls.
What AWS WAF does well for API traffic
AWS WAF evaluates HTTP requests against rules and managed rule groups. For API workloads, it is well suited to reducing common exploit traffic, blocking known unwanted patterns, enforcing IP or geographic policy, applying request-rate controls, and adding an edge layer before application code is reached.
Request filtering
Match on headers, URI paths, query strings, bodies, IP characteristics, and other request attributes.
Managed rule groups
Use maintained rule sets as a starting point for common web attack patterns.
Rate-based controls
Throttle or block sources that exceed defined request rates.
Operational integration
Apply policy close to AWS ingress services and connect findings to AWS logging and monitoring.
AWS documents that WAF rules associated with an API Gateway REST API are evaluated before other API Gateway access-control features. This makes WAF an early filtering layer, not a replacement for those later identity controls.
What a WAF cannot decide for your application
A WAF sees HTTP traffic; it usually does not know the complete business relationship between the authenticated principal and the requested object. If GET /accounts/123 and GET /accounts/456 are both valid requests, a WAF cannot infer that only one account belongs to the caller unless that business context is supplied and enforced elsewhere.
| Security question | AWS WAF role | Application / API role |
|---|---|---|
| Does the payload match known malicious patterns? | Strong fit | Secondary validation |
| Is this token valid and intended for this API? | Not primary function | Authorizer / identity layer |
| May this user access object 456? | Insufficient business context | Object-level authorization |
| May this role invoke an admin function? | Can assist with coarse conditions | Function-level authorization |
| Is this valid request sequence abusive? | Limited without business context | Behavior / business-logic detection |
A layered AWS API security architecture
- Use AWS WAF to reduce unwanted HTTP traffic and common exploit patterns at the edge.
- Use API Gateway authentication and authorizers appropriate to the API and identity model.
- Validate token issuer, audience, scope, and expiry.
- Enforce object-, property-, and function-level authorization in the application or shared policy layer.
- Apply schema, size, pagination, query-cost, and resource-consumption controls.
- Monitor API behavior for enumeration, abnormal sequences, credential abuse, and business-logic anomalies.
- Centralize logs so WAF, gateway, identity, application, and runtime API events can be correlated.
The exact architecture varies by service. API Gateway REST APIs, HTTP APIs, AppSync GraphQL APIs, ALB-backed services, and CloudFront-fronted workloads do not all expose identical integration points, so teams should verify current AWS documentation for the service being protected.
Build WAF rules around observable abuse, not maximum rule count
A productive WAF program starts in count or monitoring mode for rules that may affect legitimate API clients, then moves to blocking after traffic is understood. APIs are often called by SDKs, machine workloads, mobile apps, and partners whose request shapes differ from browsers, so blindly enabling web-oriented rules can create false positives.
- Separate policies by application or API risk where practical.
- Use managed rules as a baseline, then tune exclusions narrowly.
- Apply explicit size constraints to endpoints that should accept small payloads.
- Use rate-based rules as one layer, while keeping identity-aware quotas in the API layer.
- Protect administrative or rarely used routes with stricter conditions.
- Review sampled requests and false positives before expanding blocking.
Keep authentication and authorization outside the WAF decision
API Gateway and application identity controls should remain authoritative for who can invoke operations. AWS security guidance recommends configuring authorization on routes rather than leaving APIs open by default.
For JWT or OAuth-style access, verify audience and issuer, map scopes to operations, and still perform object-level authorization after the target resource is known. For workload identity, use narrowly scoped IAM or service credentials and avoid credentials that grant an entire service more access than it needs.
GraphQL and other single-endpoint APIs need deeper controls
GraphQL often sends many logical operations to one HTTP path, which reduces the value of path-only WAF policy. Protect GraphQL with operation-aware authentication, resolver authorization, depth and complexity limits, batching controls, field restrictions, and runtime monitoring.
The same principle applies to RPC or generic command endpoints: the security meaning is inside the operation and arguments, not merely the URL. Edge filtering remains useful, but deeper API context becomes more important.
Differentiate HTTP abuse from business abuse
AWS WAF and bot-oriented controls can help reduce automation, but API abuse can use valid credentials and legitimate request shapes. Examples include inventory hoarding, promotion abuse, account enumeration, repeated password-reset workflows, credential stuffing across distributed addresses, or transaction manipulation.
Edge abuse
Known exploit patterns, obvious scanners, unwanted IPs, bursts of traffic.
Identity abuse
A valid or compromised account accesses far more objects than normal.
Workflow abuse
Valid calls are sequenced to exploit a business rule or scarce resource.
Authorization abuse
A valid token reaches objects or functions outside its entitlement.
Correlate AWS WAF data with API and identity telemetry
A WAF log is most useful when it can be tied to the gateway request, authenticated principal, API operation, backend result, and security outcome. Correlation helps distinguish blocked internet noise from a targeted attack using valid credentials.
- Track WAF rule matches and blocks by API route or service.
- Track authorization failures and object-access anomalies by identity.
- Measure 4xx/5xx changes after rule updates to catch accidental blocking.
- Alert on unusual combinations such as valid authentication plus repeated forbidden object access.
- Retain enough context for incident response without logging secrets or full sensitive payloads.
When AWS WAF is enough—and when it is not
For a simple public API with limited data and strong application authorization, WAF plus gateway and application controls may cover the required risk. As APIs become multi-tenant, business-critical, partner-facing, GraphQL-based, or highly automated, dedicated API discovery and behavior controls become more valuable.
| Requirement | WAF alone? | Additional capability |
|---|---|---|
| Block common web exploits | Often useful | Secure coding and patching remain required |
| Discover shadow or undocumented APIs | No | API discovery / inventory |
| Prevent BOLA / IDOR | No | Object-level authorization |
| Detect abnormal valid-user sequences | Limited | Behavior and business-logic analytics |
| Protect expensive operations | Partly | Operation-aware quotas and resource controls |
Frequently asked questions
Can AWS WAF protect API Gateway?
Yes. AWS WAF can be associated with supported API Gateway REST API stages and evaluates matching requests before API Gateway access-control features. Verify current service support for the API type you use.
Is AWS WAF enough for API security?
No for most nontrivial APIs. It is a valuable request-filtering layer but does not replace authentication, object authorization, function authorization, business-logic controls, discovery, or secure application design.
Can AWS WAF prevent BOLA or IDOR?
Not reliably by itself. BOLA requires knowledge of whether the authenticated caller is entitled to the specific requested object, which normally belongs in application or policy-layer authorization.
Should AWS WAF rate limits replace API quotas?
No. WAF rate controls are useful at the edge, while API quotas should also consider identity, operation cost, tenant, and business context.
How should teams tune WAF rules for APIs?
Start with observed traffic, use managed rules as a baseline, monitor or count where false positives are possible, tune narrowly, then move appropriate rules to blocking with regression monitoring.
Sources and further reading
- AWS — Use AWS WAF to protect API Gateway REST APIs — official API Gateway WAF integration guidance
- AWS WAF Documentation — official AWS WAF documentation
- Amazon API Gateway Security Best Practices — official API Gateway security guidance
- OWASP API Security Top 10 — 2023 — API-specific risk framework
Protect APIs with runtime context, not just static rules
Ammune helps security teams discover APIs, understand normal behavior, detect abuse and authorization anomalies, and apply runtime protection across modern API environments.