Why do WAFs and in-app runtime controls catch different attacks?

Why the two controls catch different classes of abuse

A WAF and an in-app runtime control are looking at the same request from different trust boundaries, so they do not fail or succeed on the same signals. The WAF works before application logic runs, which makes it good at spotting malformed payloads, obvious exploit patterns, and edge-volume abuse. An in-app control sees the request after parsing, routing, authentication, and business logic decisions, so it can block behaviour that only becomes dangerous inside the code path.

That difference matters because many attacks are only visible once input is interpreted. A payload that looks harmless at the edge may become dangerous when a framework decodes it, concatenates it into a query, or passes it to a privileged function. In-app controls can therefore enforce context-aware checks that a network boundary cannot reliably infer.

What each control is actually observing

A WAF is primarily a request-shape filter. It can inspect headers, paths, parameters, and body patterns, then decide whether the traffic resembles a known malicious signature or an abnormal request pattern. It is strongest where the attacker’s technique is externally visible, repetitive, or noisy enough to distinguish from normal traffic.

An in-app runtime control is a code-adjacent decision point. It can see whether the request came from a trusted workflow, whether the current user or session should be allowed to reach a function, and whether an input would be dangerous only after internal transformation. That makes it better suited to blocking injection, privilege-sensitive actions, and cases where the real risk depends on application state rather than just request syntax.

The practical implication is that the same payload can produce different outcomes. One control may reject a request because it matches an exploit pattern, while the other may allow the request but stop it later because the execution context does not permit the resulting action. That is why mature applications often use both layers rather than treating them as interchangeable.

Why layered detection improves coverage instead of duplicating it

These controls are complementary because they reduce different blind spots. A WAF helps absorb commodity attacks, scripted probing, and large-scale noise before the application spends resources processing them. In-app controls protect against requests that are syntactically valid, tailored to the application, or only harmful once the code reaches a sensitive sink.

Used together, they provide defense in depth across the request lifecycle. The edge layer can eliminate broad attack traffic early, while the application layer can make the final authorization or safety decision with full knowledge of context. That combination is especially important when business logic, object access, or input handling cannot be safely inferred from packet or header inspection alone.

For teams comparing controls, NIST SP 800-190 Container Security is useful here because it frames runtime protection as part of the application trust boundary, not just a perimeter filter. If your application depends on cloud roles or other backend access paths, the distinction becomes even sharper, as shown in Capital One breach 2019, where edge controls did not prevent abuse that emerged deeper in the request path.

Risk and Threat Considerations

The main risk is assuming that one control can compensate for the other. If you rely on a WAF alone, attacks that are semantically valid but contextually unsafe can still reach dangerous application logic. If you rely only on in-app controls, you may still absorb large volumes of cheap probing, automated exploitation, and denial-style traffic that should have been filtered earlier.

Failure mechanism: The WAF sees surface syntax, while the application sees execution context. Attackers exploit that gap by crafting requests that look ordinary until the code parses, routes, or dereferences them into a sensitive action, or by shifting to payloads that evade edge signatures but still trigger unsafe behaviour inside the app.

Impact: The result can be missed injection, unauthorized function execution, excessive load on the application tier, or inconsistent blocking across environments. In the worst case, a request that should have been stopped at the boundary reaches a privileged sink and turns a simple input flaw into real compromise.

Practitioner Guidance

What to verify: Check whether the WAF and the application are enforcing different decisions on the same test cases, especially for encoded input, parameter pollution, and requests that only become dangerous after parsing or object resolution. If both layers always make the same decision, one of them may be redundant or misconfigured.

Decision rule: Use the WAF to absorb broad, externally visible abuse and the in-app control to enforce context-sensitive safety where request meaning depends on code, state, or privilege. If a control depends on knowing the business object, session, or sink, it belongs closer to the application.

Practitioner takeaway: Do not treat perimeter filtering and runtime safety as substitutes, because the right design is to stop obvious abuse early and still make the final allow or block decision at the point where the application actually understands the request.

Related resources from NHI Mgmt Group

• Why do browser-based attacks need different hunting controls than endpoint threats?
• Who is accountable when browser-based attacks bypass app login controls?
• Why do AI agent access paths need different controls from ordinary app integrations?
• What breaks when mobile app hardening is the main control against runtime attacks?