WAAP is becoming the baseline for web and API attack defence

At a glance

What this is: This is an analysis of why Web Application and API Protection has become the default control layer for modern application defence, driven by API abuse, bot activity, and the limits of traditional WAFs.

Why it matters: IAM, application security, and platform teams need to treat API discovery, request authorisation, and runtime behaviour as governance problems, because legacy perimeter filtering no longer covers the full attack path.

By the numbers:

• LEVO cites more than 271 million API attacks in a single quarter of 2024.
• LEVO says APIs faced roughly 85% more attacks than standard web applications.
• LEVO notes that the average data breach now costs enterprises 4.45 million dollars.
• LEVO reports that more than 80 percent of web traffic is encrypted.

Context

WAAP, or Web Application and API Protection, is the control category that sits between basic perimeter filtering and full application-aware enforcement. The core governance gap is that web apps and APIs now change too quickly, and are probed too continuously, for static WAF rules to remain sufficient on their own.

That gap matters because API discovery, schema validation, object-level authorisation, bot management, and DDoS mitigation now operate as one risk surface rather than separate technical chores. Where APIs expose tokens, customer data, or business logic, the security problem becomes identity-adjacent as well as application-layer: request legitimacy depends on both the caller and the action being attempted.

The article’s starting position is typical of modern cloud-native environments: application delivery teams move faster than perimeter rule tuning can keep up, and attackers take advantage of that mismatch.

Key questions

Q: What breaks when a WAF is used without WAAP for modern APIs?

A: A WAF alone often misses the controls that matter most for APIs, including discovery, schema validation, object-level authorisation, and behavioural abuse detection. That leaves teams exposed to shadow endpoints, BOLA-style requests, and bot-driven attacks that look legitimate at the packet layer but are unsafe at the application layer.

Q: Why do APIs need different controls from traditional web applications?

A: APIs expose structured requests, machine-to-machine access, and business actions that are not visible in the same way as browser traffic. Security teams need controls that understand request intent, object scope, and runtime behaviour, because a technically valid call can still be unauthorised or abusive.

Q: How do security teams know whether WAAP is actually reducing risk?

A: Look for fewer successful abuse attempts, lower false-positive rates, complete coverage of critical APIs, and telemetry that shows blocked anomalies without breaking legitimate traffic. If the platform only adds alerts but does not improve enforcement on high-value endpoints, it is not changing risk materially.

Q: Should teams prioritise API discovery or enforcement first?

A: Discovery comes first when shadow endpoints or incomplete inventories exist, because enforcement cannot protect what the team has not identified. Once the exposed surface is known, prioritise the most sensitive and most attacked APIs for schema validation, bot controls, and runtime enforcement.

Technical breakdown

Why WAF logic breaks down against API discovery and schema abuse

Traditional WAFs were built around web pages, HTML forms, and known signatures. APIs behave differently because the meaningful control point is not just the URL or method, but the shape of the request, the object being referenced, and the business action implied by that call. When an attacker probes hidden endpoints, mutates JSON fields, or reuses identifiers, a ruleset tuned for page traffic often misses the abuse or creates too many false positives to keep blocking enabled.

Practical implication: validate API schemas and object access paths, not just edge traffic patterns.

How bot automation and credential abuse overwhelm legacy perimeter controls

Bot traffic turns application defence into a scaling problem. A perimeter tool that only recognises generic bad signatures cannot reliably distinguish human sessions from scripted abuse, especially when attackers rotate IPs, vary payloads, or imitate normal browsing speed. That matters for credential stuffing, scraping, and Layer 7 floods because the security decision depends on behavioural context and request intent, not just packet inspection. In a WAAP model, bot management becomes a control layer in its own right, rather than a tuning add-on.

Practical implication: treat bot classification and abuse throttling as first-class controls for login and API endpoints.

Why runtime context changes API security from filtering to enforcement

Runtime-aware protection adds information that edge-only inspection does not have. It can see which services call each other, what data flows are normal, and which requests violate observed behaviour even if they are syntactically valid. That is especially important for business logic abuse and BOLA-style requests, where the attack looks like legitimate API use until the context is checked. The shift is from blocking bad inputs to enforcing acceptable runtime behaviour across the full application path.

Practical implication: use runtime context to enforce behaviour-based controls for high-risk APIs and service calls.

Threat narrative

Attacker objective: The attacker wants to extract data, automate abuse at scale, or disrupt application services without triggering basic perimeter defences.

1. Entry occurs through exposed web or API endpoints that lack deep discovery and schema-aware enforcement, allowing attackers to identify usable surfaces.
2. Credential harvesting or abuse follows when automated bots, replayed sessions, or identifier manipulation let the attacker test requests at scale.
3. Escalation happens through business logic abuse, excessive data access, or Layer 7 pressure that bypasses legacy WAF assumptions.
4. Impact is exposed customer data, service disruption, or unauthorised access to critical application workflows.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

WAAP is becoming the practical baseline because application security has shifted from page protection to request governance. The article’s central point is not that WAFs disappeared, but that they no longer cover the full decision space around modern APIs. Once endpoints become dynamic and distributed, request legitimacy depends on schema, caller context, and runtime behaviour. Practitioners should treat WAAP as the minimum control layer for externally reachable applications.

API security is now an identity-adjacent governance problem, not just an application filtering problem. A valid API request can still be abusive if the caller should not reach that object, field, or workflow. That makes access control, object-level authorisation, and behavioural enforcement part of the same control conversation. Teams that separate IAM from API defence will continue to miss the exploit path that turns authenticated traffic into unauthorised activity.

Shadow APIs create a visibility debt that no perimeter rule set can fully absorb. The article’s inventory advice is sound because undiscovered endpoints are effectively unmanaged exposure. This is where the control problem starts for both human and machine identities: if you cannot inventory the surface, you cannot govern who or what is allowed to use it. Practitioners should treat discovery as a prerequisite for any credible WAAP programme.

WAAP plus runtime context narrows the gap between prevention and observability. Static inspection can block known badness, but it cannot explain why a request is suspicious inside a live service topology. Behavioural enforcement, paired with runtime signals, gives teams a better model for business logic abuse and lateral movement through APIs. The field is moving toward continuous application governance, not one-time perimeter hardening.

What this signals

Shadow API governance: the hard part is no longer deciding whether to protect APIs, but proving that the inventory is complete enough to trust enforcement decisions. If shadow endpoints remain outside policy scope, WAAP becomes a partial control rather than a governing layer.

API protection is increasingly where identity, application security, and runtime operations meet. That convergence means practitioners should expect more pressure to align request authorisation, behavioural analytics, and SOC telemetry around the same set of high-risk services.

For practitioners

• Inventory every exposed web application and API Build a complete catalogue of internet-facing services, shadow endpoints, and partner integrations before onboarding policy. Rank them by data sensitivity, business impact, and exposure so that the highest-risk APIs are protected first.
• Enforce schema and object-level checks Require request validation against approved schemas and object identifiers, especially for JSON and GraphQL traffic. Pair that with authorisation logic that checks whether the caller should reach the object, not just whether the request is syntactically valid.
• Run WAAP in monitor mode before blocking Use a learning period to separate benign variation from true abuse, then move to enforcement in stages. This reduces false positives and avoids disabling controls because the team fears breaking legitimate flows.
• Feed WAAP telemetry into SOC workflows Send WAAP logs to the SIEM and correlate them with IAM anomalies, service logs, and bot indicators so analysts can spot coordinated API abuse, not isolated alerts.
• Test high-risk API paths under adversarial load Exercise login, search, checkout, and data retrieval flows with bot-like volume and identifier probing to confirm that throttling, anomaly detection, and response shaping still hold under pressure.

Key takeaways

• WAAP is becoming the control baseline because modern attacks target application logic, machine-to-machine calls, and bot abuse that traditional WAF rules do not govern well.
• The biggest operational gap is visibility, since undiscovered APIs and shadow endpoints cannot be defended with confidence.
• Practitioners should pair discovery, schema validation, and runtime enforcement so application protection keeps pace with development and attacker automation.

Key terms

• Web Application and API Protection: Web Application and API Protection is the set of controls used to secure websites, web apps, and the APIs they expose. It combines traffic inspection, authentication, authorization, input validation, threat detection, and abuse prevention to reduce attacks such as injection, credential theft, scraping, and automated misuse across application interfaces.
• API Discovery: API discovery is the process of finding and cataloging APIs across an environment so security teams know what exists, what data it exposes, and how it behaves. It is essential because shadow, zombie, unmanaged, and third party APIs are frequent blind spots that attackers can exploit without being noticed.
• Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
• Bot Management: Bot management is the set of controls used to detect, challenge, and stop automated traffic that imitates legitimate users. In identity and fraud programmes, it protects login, checkout, and session flows from account takeover, scraping, and credential stuffing while preserving access for real customers.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security practitioners connect identity governance to the broader security programme they are responsible for.