Notifications
Clear all
Topic starter
06/09/2026 3:45 pm
TL;DR: WAFs and WAAP platforms reduce perimeter risk in modern application environments, but LEVO argues they still stop at request inspection and cannot validate authorization correctness, data exposure, or internal API behaviour after traffic is accepted. Runtime API security becomes the missing layer for proving that APIs behave safely in production, not just that they filter attacks at the edge.
NHIMG editorial — based on content published by LEVO: WAF, WAAP, and runtime API security analysis
Questions worth separating out
Q: When should organisations rely on WAF, WAAP, and runtime API security together?
A: Use all three when applications are API-heavy, distributed, or identity-driven.
Q: Why do WAF and WAAP fail to stop broken authorisation in APIs?
A: Because both tools inspect requests before application logic runs.
Q: How do security teams know if runtime protection is actually working?
A: Look for evidence that suspicious behaviour is detected fast enough to contain it before the session or workload expands the blast radius.
Practitioner guidance
- Define a three-layer API control model Use WAF for classic web attack filtering, WAAP for API-aware edge inspection, and runtime API security for execution-level validation of authorization and data handling.
- Map identity-bearing API paths Inventory service accounts, delegated tokens, partner callbacks, and internal endpoints so teams can see where authentication occurs and where authorization is actually enforced.
- Prioritise runtime checks for object-level access Target APIs that return customer, patient, financial, or configuration data and verify that the caller can only access the objects and fields intended for that identity.
What's in the full article
LEVO's full article covers the operational detail this post intentionally leaves for the source:
- Concrete examples of when WAF remains the right control for legacy and form-based applications.
- Practical distinctions between WAAP coverage and runtime API security across public, internal, and partner-facing APIs.
- Specific examples of business logic flaws and object-level authorization failures that edge controls cannot see.
- Operational guidance on where runtime validation should sit in a layered application security model.
👉 Read LEVO's analysis of WAF, WAAP, and runtime API security →
WAF, WAAP and runtime API security are not interchangeable?
Explore further
06/09/2026 3:45 pm
Edge controls are necessary, but they are not assurance controls. WAF and WAAP reduce exposure to known attack patterns, yet they only validate traffic before application logic executes. The governance problem is that many security teams still confuse request filtering with behavioural correctness. For API-heavy estates, that is a dangerous assumption because the real access decision often happens after the edge. The practical conclusion is that perimeter protection should be treated as a first layer, not a proof of safe operation.
A question worth separating out:
Q: What is the difference between WAAP and runtime API security?
A: WAAP inspects and enforces at the edge using schema, structure, and behavioural signals. Runtime API security observes what happens after a request is accepted, including authorization outcomes, data exposure, and service-to-service behaviour. The practical difference is that WAAP reduces bad traffic, while runtime security proves that the application behaves correctly.
👉 Read our full editorial: WAF, WAAP and runtime API security: why edge controls fall short
