WAF, WAAP and runtime API security: why edge controls fall short

At a glance

What this is: This is an analytical comparison of WAF, WAAP, and runtime API security, showing that edge controls solve different problems but cannot verify API behaviour after request acceptance.

Why it matters: It matters because IAM, PAM, and application security teams need evidence of authorization correctness and data handling, not just perimeter filtering, especially in API-heavy environments with identity-driven access paths.

👉 Read LEVO's analysis of WAF, WAAP, and runtime API security

Context

Modern application security has shifted from a single web perimeter to distributed APIs, mobile clients, microservices, and third-party integrations. That change matters for identity security because access is no longer decided only at login or by a front-door filter; it is also enforced inside runtime paths, where object-level authorization, service-to-service trust, and data handling can fail.

WAF and WAAP both remain useful, but they were built to inspect requests before application logic runs. That means they can reduce obvious attack traffic without proving that an authenticated caller is entitled to the data or actions the API returns. For teams responsible for IAM, NHI, and application governance, the gap is between traffic inspection and behavioural assurance.

Key questions

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. WAF filters classic web attacks, WAAP adds API-aware edge inspection, and runtime API security validates what happens after acceptance. If you only have perimeter controls, you can reduce noise without proving that access, data return, and internal workflows are safe.

Q: Why do WAF and WAAP fail to stop broken authorisation in APIs?

A: Because both tools inspect requests before application logic runs. They can block malformed or obviously malicious traffic, but they cannot confirm whether a valid token is entitled to a specific object, field, or transaction. Broken object-level authorization is a runtime failure, so the edge may see normal traffic while the application discloses data incorrectly.

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. Effective runtime protection produces actionable alerts, ties them to containment steps, and shows that abnormal access can be limited during active execution, not only reviewed afterward.

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.

Technical breakdown

How WAF inspection differs from application execution

A WAF inspects inbound web traffic for known attack patterns such as SQL injection, cross-site scripting, and cross-site request forgery. It works well when the application surface is dominated by HTML forms and predictable request shapes. Its visibility ends when the request passes to application logic, so it cannot judge whether a valid request is authorised, whether returned data is appropriate, or whether downstream services handle it safely.

Practical implication: keep WAFs for perimeter filtering, but do not treat them as evidence that the application is behaving correctly.

Why WAAP extends protection but still stops at the edge

WAAP adds API-aware inspection, including JSON and XML schema validation, behavioural analysis, and bot detection. That improves coverage for API-first environments, especially where structured payloads and automated abuse are common. But WAAP still makes its decision before execution. If a request is authenticated and structurally valid, the platform may allow it through even when the underlying business logic is flawed or the caller should not access the referenced object.

Practical implication: use WAAP to reduce malformed and automated abuse, then add runtime controls for authorization and data exposure validation.

Why runtime API security is a different control layer

Runtime API security observes what happens after acceptance. It focuses on execution-level behaviour, including object-level authorization, response content, internal service calls, and shadow or undocumented endpoints that perimeter tools may never see. In identity terms, this is where the trust decision is actually enforced, which is why runtime validation is essential in environments with delegated access, service accounts, and distributed workloads.

Practical implication: instrument runtime paths to verify that the API enforces access decisions, not just that the request looked legitimate.

NHI Mgmt Group analysis

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.

Runtime API security is where identity control meets application reality. APIs increasingly carry identity-bearing decisions through service accounts, delegated tokens, and machine-to-machine flows. Once a request is accepted, the question becomes whether the caller is entitled to the object, field, or transaction returned by the system. That is an IAM and NHI problem as much as an application problem. Practitioners should treat runtime validation as the place where access policy, data minimisation, and execution behaviour must converge.

Behavioural assurance is the named gap this article exposes. We can call it the runtime assurance gap: controls that confirm traffic shape without confirming system behaviour. This gap matters because schema-compliant requests can still produce broken object-level authorization, overexposure, or unsafe internal flows. Security leaders should reframe API protection around evidence of behaviour, not just evidence of blocked attacks.

The category is moving from prevention-only tooling toward evidence-based control. The more distributed and API-driven the environment becomes, the less useful it is to measure success by edge rejection rates alone. Teams need proof that internal APIs, partner callbacks, and microservice paths behave consistently with policy. That shifts governance from perimeter hygiene to operational verification, which is the direction identity-aware application security is heading.

Identity governance now extends beyond login into runtime decisions. When access is mediated by tokens, service identities, and delegated trust, the important question is not only who authenticated, but what the application allowed that identity to do. That makes runtime API security directly relevant to IAM and NHI programmes. The practitioner takeaway is simple: if access can be approved at the front door but violated inside the house, the control model is incomplete.

What this signals

Runtime assurance will become a standard expectation in API-heavy identity programmes. Once applications rely on delegated tokens, service accounts, and partner callbacks, the security team needs proof that behaviour matches policy after the request is accepted. That makes runtime API validation a governance requirement, not an optional enhancement, especially where identity, access, and data flow intersect.

The runtime assurance gap is the control problem teams should name now. It captures the difference between blocking suspicious traffic and verifying that legitimate traffic does not produce unauthorised outcomes. As organisations add more machine identities and third-party integrations, that gap will widen unless runtime checks are built into the operating model.

The strongest programmes will stop asking whether the edge blocked the request and start asking whether the application returned the right data to the right identity. That shift aligns application security with identity governance and makes access correctness observable in production.

For practitioners

• 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.
• Treat undocumented endpoints as governance debt Find internal, shadow, and configuration-exposed APIs that never pass through edge enforcement, then bring them into monitoring, policy review, and access review workflows.

Key takeaways

• WAF and WAAP are important perimeter controls, but they cannot prove that APIs behave safely after request acceptance.
• The evidence gap is behavioural, not cosmetic: schema-compliant traffic can still produce unauthorised access and data overexposure.
• Runtime API security closes the gap by validating execution, authorization outcomes, and internal flows in production.

Key terms

• Web Application Firewall: A web application firewall inspects HTTP traffic and applies rules to detect or block malicious requests and responses. Unlike a network firewall, it understands application-layer content such as headers, parameters, and body fields, which lets it catch attacks like injection and path probing.
• API Edge Protection: A security approach that inspects and controls API traffic at the point where it enters the enterprise. It combines authentication, rate control, risk scoring, and behavioural analysis to stop malicious requests before they reach backend services or data stores.
• API-Based Email Security: API-based email security integrates with the mail platform through application interfaces rather than sitting in front of traffic. This lets security teams inspect delivered messages, automate remediation, and connect email actions to mailbox and identity context in cloud-native environments.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.

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.

👉 LEVO's full article explains the control boundaries, failure modes, and runtime gaps in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance and secrets management for practitioners who need to connect identity controls to operational risk. It gives security leaders a practical way to strengthen access governance across modern environments.