How the correlation works
This rule fires when both of these happen within a 5-minute window for the same source IP and target URL:
Your WAF flags a request (any WAF detection — blocked, allowed, or logged)
Contrast ADR confirms that the same request resulted in a confirmed exploit at the application code level
Because the WAF and ADR see the same HTTP request nearly simultaneously, the 5-minute window is tight and precise.
What this means in practice:
WAF is in… | What happens | What the correlation tells you |
Detect/alert mode | WAF logs the suspicious request but allows it through. ADR sees the request and confirms exploitation. | The WAF alert was correct. This is a confirmed exploit. Act on it. |
Block mode | WAF blocks the request. Payload never reaches the app. ADR sees nothing. | No correlation fires. The WAF handled it. Nothing for the SOC to do. |
Block mode, but the attacker bypasses | WAF blocks some requests, but the attacker re-encodes the payload. WAF may alert on the original attempts. ADR sees the bypassed request and confirms exploitation. | WAF bypass detected. The attacker found a way around the WAF. Update WAF rules and enable ADR Block Mode as defence-in-depth. |
The rule is source-agnostic — it works with any WAF that sends logs to your SIEM: ModSecurity, AWS WAF, Cloudflare, Imperva, F5 BIG-IP ASM, Akamai, Azure WAF, Barracuda, Fortinet, Radware, Signal Sciences, Fastly.