How should security teams layer WAF, RASP, and ADR for application protection?

How the three layers divide responsibility

WAF, RASP, and ADR work best when each is assigned the part of the attack path it can actually see. A WAF is strongest at the edge, where it can filter obvious malicious traffic, block commodity abuse, and reduce noise before requests reach the app. RASP acts inside the process, where it can make a more precise decision at the sink. ADR adds host-level visibility when you need detection beyond the application boundary.

The practical point is that these tools are not substitutes for one another. A request blocked at the edge may never exercise the code path, while a runtime control may see the exact function call or sink that matters. Host telemetry then becomes valuable when you care about process behaviour, suspicious child processes, credential misuse, or signs that the application has already been reached and abused.

For teams building the stack, the right question is not which product is “best”, but which control sees the attacker earliest in the phase you care about most. That is why layered application protection often combines perimeter filtering, in-app enforcement, and endpoint or host detection rather than trying to force one tool to do all three jobs.

Where each control is strongest in practice

Use a WAF when the problem is clearly network-facing: malformed requests, exploit probes, noisy automation, and volumetric or HTTP-level abuse. NHIMG’s Web Application Firewall Guide is the right starting point if you need to think through deployment modes, tuning, false positives, and virtual patching. The main limitation is that a WAF only sees what crosses its boundary, so it cannot reliably judge business logic, post-authentication behaviour, or every in-process sink.

Use RASP when you need decisions closer to the vulnerable code path. That is especially useful for precise sink-level blocking, such as stopping unsafe deserialisation, command execution, injection, or other dangerous operations after the request has already entered the application. NHIMG’s Interactive Application Security Testing and RASP Guide is useful here because it explains why instrumentation and monitor mode matter when you want to see whether a runtime policy would actually stop the risky action.

Use ADR when the value comes from host context, not just request context. eBPF-based detection can show process creation, network activity, file access, library loading, and other signals that indicate exploitation or post-exploitation behaviour. That makes ADR especially useful when the app layer is blind to what happens after the request, or when you need to confirm whether a runtime event turned into a real host compromise. NHIMG’s Beaconing and C2 Detection Guide is a strong companion when host telemetry is being used to hunt for suspicious follow-on activity rather than just blocked requests.

Designing the stack by attack phase, not by product category

Good layering starts with the attack phase, then maps controls to that phase. If the main risk is brute-force noise, protocol abuse, or high-rate scanning, put the edge layer first. If the main risk is exploitation of a specific code path, put the in-app layer first. If the main risk is that compromise has already progressed into the host, then host-level detection becomes the priority. This is why the same application may need all three layers, but each layer should be justified by a different failure mode.

That also means false confidence is a real design error. A WAF can reduce exposure without proving the application is safe. A RASP policy can reduce exploitability without proving the host is clean. ADR can reveal suspicious execution without proving the original payload was blocked. Teams get the best result when they treat each layer as partial evidence and partial control, then correlate them rather than expecting one control to provide complete protection.

When the controls are aligned properly, the operational benefit is cleaner escalation. Edge filtering suppresses known bad traffic, runtime policy limits direct code execution risk, and host telemetry tells responders whether to look for exploitation, persistence, or lateral movement. The stack then supports both prevention and detection without forcing the same control to do both jobs badly.

Risk and Threat Considerations

The main risk in a layered design is over-trusting whichever control is easiest to deploy. A WAF can be bypassed by requests that look benign until they reach the application, while a runtime control may not help if the host is already compromised or if the dangerous action occurs outside instrumented code. An attacker benefits when defenders mistake “blocked at the edge” for “safe overall”, because that assumption hides deeper attack paths.

Failure mechanism: The attacker shifts from obvious payloads to request shapes, authenticated abuse, or post-exploitation actions that sit outside the visibility of a single control layer. If the organisation relies on one layer to provide all protection, blind spots become exploitable gaps.

Impact: A weak design can leave injection, business-logic abuse, process compromise, or follow-on activity undetected until the incident is already beyond the application boundary. The result is more time to detect, less reliable containment, and a larger blast radius.

Practitioner Guidance

What to verify: Validate each layer against a different test objective. The WAF should be measured on whether it stops known bad traffic without creating unacceptable false positives. RASP should be checked on whether it actually blocks the sink you care about, not just whether it logs activity. ADR should be checked on whether it exposes the host behaviours that matter during and after exploitation.

Decision rule: If the control cannot observe the phase where the attacker is most likely to succeed, do not let it stand in for another layer. Use the WAF to reduce attack volume, RASP to enforce in-process decisions, and ADR to confirm host-level compromise or suspicious follow-on activity.

Practitioner takeaway: The best application protection design is phase-aware, because no single control sees the whole attack path well enough to carry the stack alone.

Related resources from NHI Mgmt Group

• What do security teams get wrong about application-layer cloud protection?
• What is the difference between RASP and WAF in application protection?
• How should security teams implement application protection policies without relying on brittle clickops or manual WAF tuning?
• How should security teams layer API protection with AWS WAF in cloud environments?