Block mode vs. Monitor mode — Decision matrix
Factor | Monitor mode | Block mode |
What it does | Detects and reports exploits; does not interfere with execution | Detects and stops exploits in real-time; the malicious request is terminated |
Risk | Attacker’s exploit succeeds (but you know about it) | A potential false positive blocks a legitimate request |
Best for | Initial rollout, low-confidence rules, non-critical apps, learning period | High-confidence rules, critical apps with well-tested policies, and known-exploited vulnerabilities |
Start here if… | You’re deploying ADR for the first time | You’ve validated in Monitor mode and have zero/low false positives |
Recommended rollout approach:
Phase | Duration | Mode | Scope |
1 — Observe | 2–4 weeks | Monitor only (all rules) | Tier 1 (critical) applications |
2 — Validate | 1–2 weeks | Monitor + review all alerts for false positives | Tier 1 applications |
3 — Selective Block | Ongoing | Block for high-confidence rules; Monitor for the rest | Tier 1 (critical) apps first |
4 — Expand | Ongoing | Block for validated rules across broader app portfolio | All tiers |
Per-rule modes and exclusions
Each ADR rule can be independently set to Off, Monitor, or Block, either per application or organization-wide through Policy management > Protect rules. The goal is Block Mode for every ADR rule on every Tier 0 and Tier 1 app.
Because ADR detects exploitation at the code level rather than matching request patterns, Block Mode runs with a low false-positive rate, far below what perimeter tools produce. Leaving a rule in Monitor on a critical app should be a deliberate, documented decision, not a default. See Set Protect rules for more information.
Per-rule mode
Each ADR rule can be independently set to Off, Monitor, or Block, either per application or organization-wide via Policy management > Protect rules. The goal is Block Mode for every ADR rule on every Tier 0 and Tier 1 app. Because ADR detects exploitation at the code level rather than matching request patterns (see 2.3), Block Mode runs with a low false-positive rate, far below what perimeter tools produce. Leaving a rule in Monitor on a critical app should be a deliberate, documented decision, not a default. See Set Protect rules.
Exclusions are an escape valve, not a tuning step. ADR does not require exclusions to run safely in Block Mode. Exclusions exist for three narrow cases:
The application is doing something insecure that legitimately needs to keep working. At the same time, the underlying issue is fixed (e.g., a tool that passes user input directly to a shell, or an internal report that generates unparameterized SQL). Block Mode is correctly stopping the request. Add a scoped exclusion for that specific rule plus URL/input/code path, open a remediation ticket on the underlying behavior, and keep the rule in Block everywhere else.
Highly sensitive workloads where AppSec wants to constrain Block Mode to a known-good profile out of extra caution.
An emergency, when Block Mode has unexpectedly blocked a legitimate request. Prefer a scoped exclusion over a full rule disable.
If you find yourself adding many exclusions, the signal is to look at the application, not the rule. See Application exclusions and Add application exclusions.