Why do API security incidents keep rising even when organisations already have WAFs and API gateways?

API incidents persist because attackers exploit flaws in business logic and authenticated flows that traditional edge controls do not reliably understand. The report shows companies with these tools still face repeated attacks, which means visibility alone is not protection. Teams need layered controls that inspect behaviour at runtime and respond to reconnaissance before attackers reach their objective.

Why API gateways and WAFs miss the incidents that matter most

API gateways and WAFs are strongest at edge filtering, request normalization, and blocking obvious abuse patterns. They are much weaker when the attack succeeds by staying within allowed traffic and abusing legitimate business logic, object references, token handling, or state transitions. Once the request is authenticated and looks syntactically valid, edge controls often have little context to decide whether the action is intended.

That is why incidents keep rising even in mature environments. The control gap is not simply “no security,” it is that the security boundary stops at the perimeter while many API failures occur deeper in the application flow, after the gateway has already allowed the request through.

Edge controls are useful for volume, known bad patterns, and coarse filtering.
They do not reliably understand whether a legitimate user is performing an illegitimate action.
Business logic abuse often looks like normal API use until the downstream effect becomes visible.

What attackers exploit after the gateway has approved the request

Most serious API incidents are driven by abuse of authenticated flows, authorization gaps, excessive object exposure, token misuse, and automation that can replay valid requests at scale. The attacker does not need to defeat the front door if the front door is willing to admit traffic that is technically valid but operationally harmful.

In practice, the weak point is often not transport or syntax, but decision-making inside the application. When an API trusts the caller too much, or trusts the sequence of calls too much, the control problem shifts from inspection to understanding intent, state, and entitlement. That is why runtime behaviour, not just request shape, becomes the decisive layer.

Behavioural abuse can be indistinguishable from normal use at the edge.
Authenticated flows can be exploited through over-permission, replay, chaining, or enumeration.
Reconnaissance often precedes the exploit, so early detection of probing matters.

What closes the gap in practice

The strongest response is layered: keep WAFs and gateways for perimeter protection, but add controls that observe API behaviour in context, validate authorization at the point of action, and flag unusual sequencing, volume, or object access. The aim is to detect when a request is permissible in form but suspicious in effect.

For teams that want to reduce incident recurrence, the practical move is to instrument the API paths that create business impact, not just the paths that receive traffic. That includes tracing high-value actions, monitoring abnormal access to resources, and treating reconnaissance as a signal rather than waiting for confirmed exfiltration or fraud.

Inspect requests at runtime where business logic is enforced, not only at the edge.
Correlate identity, session, and object access patterns to find abuse that looks “legitimate.”
Prioritise high-value operations, because that is where successful API abuse becomes material.

Risk and Threat Considerations

API exposure is especially dangerous because the attacker can work inside permitted workflows, which makes detection slower and response more ambiguous. The result is repeated compromise of sensitive actions or data even when perimeter tooling appears healthy.

Failure mechanism: The gateway approves a request that is syntactically valid, but the application later applies it to a high-value object, privileged function, or sensitive business process without enough contextual validation.

Impact: Attackers can enumerate data, manipulate transactions, or chain valid calls into fraud, data theft, or privilege abuse without triggering traditional edge denial patterns.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10, 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 Agentic AI Top 10	A1 — Agent Goal Hijacking	API abuse often succeeds by steering valid flows toward unintended outcomes.
	A3 — Tool Misuse	APIs function as tools that can be abused through legitimate access paths.
	A5 — Identity and Privilege Abuse	Repeated incidents often stem from authenticated access being overtrusted.
Recommendation — Validate high-impact API actions against intended workflow boundaries. Constrain API-enabled actions to the smallest necessary privileges. Enforce per-action authorization and monitor for privilege abuse.
OWASP Non-Human Identity Top 10	NHI-03 — Overprivileged Non-Human Identities	API abuse is amplified when machine credentials can reach too much.
	NHI-07 — Secrets Exposure and Misuse	API incidents often begin with stolen or misused tokens and keys.
Recommendation — Reduce machine credential scope to the minimum required API surface. Rotate exposed API credentials quickly and track where they are used.
NIST CSF 2.0	PR.AC — Access Control	The issue is inadequate authorization and contextual enforcement on API actions.
	DE.CM — Continuous Monitoring	Runtime behaviour monitoring is needed to spot API abuse beyond the edge.
Recommendation — Apply access controls that validate what each API call may do. Monitor API behaviour for abnormal sequencing, volume, and object access.
CIS Controls v8	6 — Access Control Management	API incidents persist when permissions and trust are broader than needed.
	8 — Audit Log Management	Behavioural detection depends on logs that preserve API call context.
Recommendation — Review and remove unnecessary API permissions and access paths. Log high-value API actions with enough context to investigate abuse.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Public APIs are a common initial access path for logic and auth abuse.
Recommendation — Hunt public API abuse as an initial-access and exploitation pathway.

Practitioner Guidance

What to prioritise: Focus first on the API operations that move money, expose records, change entitlements, or alter state. Those paths deserve stricter authorization checks, tighter monitoring, and sharper anomaly detection than low-value read endpoints.

What to verify: Test whether the control still works after authentication, across object boundaries, and across call sequences. If a request is allowed simply because it came from a trusted client or a valid session, the control is probably too shallow.

Practitioner takeaway: A WAF and gateway reduce noise, but they do not prove that the requested action is appropriate, so the real security gain comes from validating intent and entitlement at the point where the API changes something important.