Notifications
Clear all
Topic starter
06/09/2026 3:45 pm
TL;DR: API WAFs often stay quiet while active abuse unfolds because valid, schema-compliant, rate-limited requests can still be malicious when viewed as a sequence, according to LEVO. The real control gap is behavioural context across identities, objects, and time, not request validation at the perimeter.
NHIMG editorial — based on content published by LEVO: Why API WAFs Miss Active Abuse
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What fails when API WAFs inspect requests but not behaviour?
A: The control fails at the point where individual requests look legitimate but the sequence becomes abusive.
Q: Why do valid credentials create so much risk in API environments?
A: Valid credentials are risky when the API trusts them too broadly.
Q: How do security teams know if API abuse controls are working?
A: Security teams know API abuse controls are working when repeated credential use drops, abnormal request volume is detected early, and hostile client behaviour is blocked before backend systems see sustained load.
Practitioner guidance
- Implement identity-linked behavioural baselines Establish normal access patterns for each API identity, including frequency, object breadth, and sequence, so low-and-slow abuse can be flagged against historical behaviour.
- Correlate object access across time windows Track which objects are accessed, how often, and in what order across longer periods, because abuse often emerges only in cumulative access patterns.
- Add controls for distributed credential use Detect when multiple credentials or services collectively produce abnormal reach even though each one remains within local thresholds and appears benign in isolation.
What's in the full article
LEVO's full analysis covers the operational detail this post intentionally leaves for the source:
- Behavioral detection logic for runtime API monitoring across identities, objects, and services
- Examples of API abuse patterns that evade perimeter controls but surface in production telemetry
- Implementation detail on how runtime API Monitoring complements API Protection without blocking legitimate traffic
- The control framing behind low-and-slow abuse, distributed access, and object traversal patterns
👉 Read LEVO's analysis of why API WAFs miss behavioural abuse →
API WAF behaviour gaps: are your controls keeping up?
Explore further
06/09/2026 3:45 pm
API behavioural blind spots are now an identity governance problem, not just an AppSec problem. When a control can validate syntax but not intent, the organisation has a governance gap around who or what is using an API credential, how often, and for what cumulative effect. That matters directly for NHI oversight because service accounts, tokens, and API keys often power the very traffic that perimeter tools cannot interpret. The discipline needs longitudinal identity telemetry, not just edge enforcement.
A question worth separating out:
Q: Should teams rely on WAFs or runtime monitoring for API abuse detection?
A: They should use both, but for different purposes. WAFs are useful for perimeter enforcement, malformed input, and known signatures. Runtime monitoring is needed for behaviour, because it correlates identities, objects, and time. Without that second layer, legitimate-looking abuse remains invisible until impact is underway.
👉 Read our full editorial: API WAFs miss behavioural abuse because they inspect requests in isolation
