Notifications
Clear all
Topic starter
06/09/2026 5:18 pm
TL;DR: Web applications and APIs now absorb most attacker attention, with LEVO citing 271 million API attacks in a single quarter of 2024, APIs facing about 85% more attacks than standard web applications, and the average breach costing 4.45 million dollars. Traditional WAFs cannot keep pace with API discovery, schema abuse, bot automation, and runtime behaviour, so WAAP has become the practical baseline for modern application protection.
NHIMG editorial — based on content published by LEVO: Web Application and API Protection for modern apps and APIs
By the numbers:
- One report recorded more than 271 million API attacks in a single quarter of 2024.
- APIs faced roughly 85% more attacks than standard web applications.
- The average data breach now costs enterprises 4.45 million dollars.
Questions worth separating out
Q: How should security teams implement WAAP in API-heavy environments?
A: Start with discovery, risk ranking, and monitor mode.
Q: Why do traditional WAF rules miss so many API and agentic attack patterns?
A: Traditional WAFs were designed around browser traffic and classic web exploits such as SQL injection and cross-site scripting.
Q: What are the signs that API protection is not working well enough?
A: Warning signs include high false-positive rates, undocumented shadow APIs, repeated probing of sequential identifiers, inconsistent schema enforcement, and bot traffic that looks normal at the edge but abnormal at runtime.
Practitioner guidance
- Inventory every exposed API and web application Build a complete list of internet-facing apps, shadow APIs, and partner integrations before deciding where WAAP enforcement should begin.
- Validate API-specific policy coverage Confirm that your platform can enforce schema validation, object-level authorisation checks, and behavioural controls for REST, GraphQL, and mobile API traffic.
- Move from monitor mode to enforcement deliberately Use monitor mode to learn normal traffic, review false positives, and tune rules before enabling blocking.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- The step-by-step WAAP deployment roadmap for monitor mode, blocking mode, and policy tuning across live applications.
- The deeper feature breakdown of API discovery, schema enforcement, bot management, and DDoS mitigation in one platform.
- The attack walkthroughs that show how WAAP responds to credential stuffing, API data exfiltration, and Layer 7 DDoS at runtime.
- The vendor's implementation guidance for choosing cloud, hybrid, or self-hosted deployment models.
👉 Read LEVO's analysis of why WAAP is replacing the traditional WAF baseline →
WAAP and API security gaps: are your controls keeping up?
Explore further
06/09/2026 5:19 pm
WAAP is now an access-governance control as much as an application control. The article shows that modern attacks increasingly exploit the boundary between valid authentication and invalid use, especially in API-heavy environments. That makes request-level enforcement part of identity governance, not just perimeter security. For NHI and IAM teams, the practical conclusion is that machine access must be evaluated in the context of request behaviour, not only token validity.
A question worth separating out:
Q: What happens when an exposed API has weak object-level authorisation?
A: Attackers can move from a valid request to unauthorised data access by changing identifiers, reusing sessions, or abusing predictable paths. The result is often data exposure rather than obvious intrusion, which is why edge filtering alone is not enough. Strong runtime and schema-aware controls limit that misuse before it scales.
👉 Read our full editorial: WAAP is becoming the baseline for web and API attack defence
