They fail because many API attacks look legitimate. Broken object level authorization, broken function level authorization, excessive data exposure, and workflow abuse often use valid requests and normal execution paths. WAFs focus on suspicious payloads, and RASP focuses on dangerous code execution. Neither can reliably tell whether the caller should be allowed to access the object or action.
Why WAF and RASP Miss API Abuse That Looks Normal
WAF and RASP are strongest when abuse leaves obvious technical fingerprints: malformed payloads, injection strings, unsafe deserialisation, or code paths that are clearly dangerous at runtime. Common api abuse patterns often do the opposite. They use valid syntax, authenticated sessions, and ordinary application behaviour, so the request may be “clean” while the abuse sits in the business meaning of the call. That is why object access, function access, and workflow misuse tend to slip past controls built around payload inspection or execution monitoring.
For API security, the core problem is not only whether a request is malicious in format, but whether the caller is entitled to the data or action it is asking for. In practice, broken object level authorisation and broken function level authorisation are authorization failures, not payload failures, so a gateway or runtime shield often has no reliable signal to stop them.
Current guidance on non-human and machine-driven access also points in the same direction: OWASP Non-Human Identity Top 10 shows why identity and entitlement problems dominate many machine-access abuse cases. In practice, many security teams discover these failures only after a legitimate-looking API path has already been used to reach data or functions that were never meant to be exposed.
How API Abuse Bypasses Technical Defenses in Practice
API abuse usually succeeds by staying inside normal application grammar. A WAF may inspect headers, parameters, and payload signatures, but it cannot infer whether user A should be allowed to read object B unless it understands the application’s authorization model. RASP has a different blind spot: it sees code execution and dangerous operations, but many abusive API calls never trigger unsafe execution. They simply invoke a permitted route with an unauthorized identifier, an overbroad role, or a business workflow that was never constrained tightly enough.
That means the decisive failures are usually in entitlement logic, not in syntax or runtime safety. Strong API protection therefore depends on controls that understand who the caller is, what it is allowed to do, and whether the requested object, function, or sequence is legitimate in context. For machine identities and automated clients, that often means tying access to explicit workload identity and short-lived authorization rather than trusting a static token or a broad network allow rule. The State of Secrets in AppSec research is relevant here because long-lived secrets and fragmented secret handling make it easier for valid-looking API traffic to originate from compromised or over-privileged callers.
- Object-level abuse is hard to catch because the request format is normal while the identifier is wrong for that caller.
- Function-level abuse often hides in allowed verbs and routes, so a block rule sees an expected operation rather than an exploit.
- Workflow abuse can chain several legitimate calls together, which defeats tools that evaluate requests one at a time.
- Excessive data exposure often reflects overbroad response design, so the control failure is in the API contract, not the payload.
Where this guidance breaks down is in APIs that rely on strong, consistent server-side authorization decisions but expose too many objects or actions through legacy endpoints, because the control gap then lives in design and entitlement enforcement rather than in anything WAF or RASP can recognise.
Common Edge Cases and What Teams Usually Overestimate
Tighter filtering can reduce noisy attacks, but it also increases the chance of false confidence if teams assume “blocked traffic” means “safe API.” The real trade-off is that payload-based controls are useful for exploit classes, while abuse patterns often require semantic and identity-aware controls.
Best practice is evolving toward layered detection: treat WAF as a boundary control for known bad input, RASP as a runtime safety net for dangerous execution, and API authorization as the primary control for object, function, and workflow abuse. There is no universal standard for this yet, but the practical rule is simple: if the attack succeeds with a valid request, the missing control is usually authorization or entitlement governance, not injection filtering.
Teams also overestimate how much rate limiting solves. Slowing a caller does not fix broken object access, and it does not stop an authenticated client from pulling the wrong records more slowly. For that reason, abuse detection should focus on anomalous access scope, unusual traversal of object IDs, and unexpected business-logic sequences rather than only on payload signatures or process-level alerts. In practice, the most damaging failures are the ones that look like ordinary application usage until the data loss or fraud is already complete.
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 NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | API abuse often rides on compromised machine credentials and valid-looking caller access. |
| NHI-03 — Authorization and Least Privilege | Broken object and function access are core entitlement failures for non-human callers. | |
| NHI-06 — Inventory and Ownership | Teams lose control when APIs, callers, and machine identities are not fully owned and tracked. | |
| Recommendation — Rotate and scope machine credentials so abused API calls cannot inherit broad standing access. Enforce least privilege and object-level checks on every non-human API request. Inventory every API-integrated identity and assign accountable ownership for its access scope. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | API abuse is controlled by validating who the caller is and what it can access. |
| DE.CM — Continuous Monitoring | Abuse patterns often appear as abnormal object access or business-logic traversal. | |
| Recommendation — Apply access controls that tie each API action to verified identity and entitlement. Monitor API call patterns for anomalous object access, function use, and workflow sequencing. | ||
| CIS Controls v8 | 6 — Access Control Management | API abuse is fundamentally an access-control problem when valid calls reach forbidden resources. |
| Recommendation — Restrict API permissions to the minimum object, function, and workflow scope required. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Public APIs are abused through exposed application logic rather than payload exploits alone. |
| Recommendation — Hunt for exposed API logic that lets attackers use valid requests to reach restricted actions. | ||
Practitioner Guidance
What to prioritise: Put authorization testing ahead of payload filtering when the abuse pattern is “valid request, invalid entitlement.” That is the point where WAF and RASP are least reliable, and where broken object and function access will usually surface first.
What to verify: Check whether every sensitive API route enforces server-side object checks, function-level checks, and workflow state checks independently of the client or UI. If any decision is delegated to the client, assume the control can be bypassed.
What good looks like: A protected API should deny access based on identity, object ownership, role, and request context even when the payload is perfectly well-formed. If enforcement only happens after parsing or execution, the design is still too late in the chain.
Practitioner takeaway: WAF and RASP are useful safety layers, but API abuse that succeeds through legitimate syntax and allowed execution paths must be stopped by entitlement-aware design and server-side authorization, not by expecting payload inspection to infer business intent.
