Because both tools inspect requests before application logic runs. They can block malformed or obviously malicious traffic, but they cannot confirm whether a valid token is entitled to a specific object, field, or transaction. Broken object-level authorization is a runtime failure, so the edge may see normal traffic while the application discloses data incorrectly.
Why Edge Controls Miss API Authorisation Decisions
WAF and WAAP are designed to inspect traffic patterns, payloads, and known attack signatures before the request is handed to the application. That makes them useful for filtering obvious abuse, but it also means they are working at the wrong layer to decide whether an authenticated caller should access a particular record, function, or tenant. Broken authorisation usually appears as a normal-looking request that is valid in syntax and transport, yet invalid in business logic. For API security, that distinction matters because the control failure is not “bad traffic entered” but “good-looking traffic was allowed to do the wrong thing.”
For teams assessing API risk, the practical issue is that edge inspection can confirm that a request exists, but not that the caller is entitled to the specific object, field, or transaction the API resolves. That is why object-level and function-level authorisation must be enforced inside the application or authorisation service, not inferred from the gateway. The broader control objective is to make entitlement decisions where identity, session state, and resource context are actually visible, which is also why API governance has to be treated differently from perimeter filtering. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates boundary filtering from access enforcement and accountability. In practice, many security teams discover this gap only after a benign-looking request has already crossed the gateway and the application has disclosed data it should never have returned.
How Broken Authorisation Survives WAF and WAAP Inspection
Broken authorisation is a runtime decision problem, not a packet inspection problem. WAF and WAAP tools can see headers, paths, parameters, and payload structure, and they may apply reputation checks or behaviour rules. They cannot reliably determine whether user A may read user B’s invoice, whether a low-privilege token may invoke an administrative action, or whether a field exposed in one context should be hidden in another. Those decisions depend on application state, tenancy, object ownership, role membership, policy context, and sometimes workflow stage.
This is why APIs can look “clean” at the edge while still being exploitable in the application layer. A request such as a legitimate GET, PATCH, or POST may pass every gateway rule and still trigger an insecure object reference, excessive data exposure, or privilege misuse once the backend resolves it. WAF and WAAP are not useless here, but their value is indirect: they can reduce noise, block known injection patterns, and slow opportunistic abuse. They do not replace per-request authorisation checks.
- Edge controls are strongest against malformed input, payload abuse, and known exploit patterns.
- Authorisation checks must happen where the application can compare the caller, the object, and the policy decision.
- API gateways can assist with authentication enforcement, but authentication alone does not prove entitlement.
- Field-level and object-level checks are often where broken authorisation becomes visible.
Teams also need to distinguish between rejection at the perimeter and denial inside the service. If the service does not re-evaluate entitlement for each sensitive action, the gateway becomes a false reassurance layer rather than a control point. This guidance breaks down where APIs are poorly designed, backend services share inconsistent policy logic, or multiple microservices each make partial authorisation decisions.
Where The Edge Still Helps, and Where It Stops
Tighter edge filtering often reduces noise but increases the risk of overestimating protection, so organisations have to balance traffic hygiene against entitlement accuracy. The useful rule is that WAF and WAAP should be treated as abuse-reduction controls, not authorisation authorities. They can still add value for rate limiting, bot suppression, schema enforcement, and blocking common exploit delivery, especially when APIs are publicly exposed.
There are important edge cases. If an API failure is driven by credential stuffing, token replay, or obvious request tampering, WAF and WAAP may reduce exposure even though they still do not fix the underlying authorisation flaw. By contrast, if the problem is an insecure direct object reference, missing ownership check, or overly broad response payload, the edge layer will usually miss it because the request is syntactically valid. That is a consensus position in API security practice, although vendors sometimes blur the boundary in marketing language.
Another common misunderstanding is assuming that stronger gateway policy automatically improves authorisation. It does not, unless the gateway is actually connected to the same policy source and the same identity context used by the service. In practice, the more distributed the API estate, the more likely authorisation drift becomes across services, versions, and teams. The control breaks down when policy is approximated at the edge instead of enforced at the resource.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 | API broken authorisation is fundamentally an access control failure. |
| Recommendation: Access checks must be enforced at the resource, not inferred from traffic hygiene. | ||
| CIS Controls v8 | 8 | Detection of broken authorisation depends on observing failed and anomalous access. |
| Recommendation: Logging should expose suspicious access patterns that perimeter tools will miss. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 | API authorisation failures often involve service-to-service and token-based access paths. |
| Recommendation: Each non-human access path needs explicit ownership and entitlement control. | ||
| MITRE ATT&CK | T1098 | Broken authorisation commonly enables privilege misuse or escalation through valid access. |
| Recommendation: Attackers abuse legitimate accounts or permissions rather than bypassing the edge. | ||
| NIST CSF 2.0 | PR.AC | The issue is access enforcement for authenticated callers, not traffic filtering. |
| Recommendation: Access control must prove entitlement after authentication and before data release. | ||
Practitioner Guidance
What to prioritise: Treat broken authorisation as an application ownership problem first, not a perimeter tuning problem. The first question is whether every sensitive API action is checked against caller identity, object ownership, and transaction context at the point of decision.
What to verify: Test for direct object reference, privilege escalation, and excessive response data using valid low-privilege accounts. If an edge control blocks only obviously malformed requests but valid callers can still reach other users’ resources, the gap is in the service logic, not the gateway.
Common mistake: Teams often accept “the WAF saw it and allowed it” as evidence of safety. That is the wrong assurance model for APIs, because authorisation failures are usually invisible to perimeter tooling unless they also trigger a separate abuse pattern.
Practitioner takeaway: WAF and WAAP can reduce hostile traffic, but they cannot prove entitlement, so any API security strategy that treats them as authorisation controls will miss the failure that matters most.
