Security · Visual Explainer
How a WAF Decides to Block
The concept
A request's journey through a WAF has five stops: it arrives, managed rule groups inspect it, matching rules attach labels, custom rules read those labels and apply business context, and then the verdict — allow, count, or block.
Key distinctions
| Term | What it means |
|---|---|
| Managed rule groups | Vendor-maintained pattern sets — SQLi, XSS, known-bad-inputs, bad bots — hundreds of rules you didn't have to write. |
| Labels | A rule can match and attach a label instead of blocking outright, so later rules can make decisions about earlier matches. |
| Count mode | The rule evaluates and logs but doesn't block — how you test any change against real production traffic before enforcing. |
| The golden rule | Never disable a whole rule group to fix a false positive — scope an override with labels so protection stays armed for everyone else. |
Why it matters in practice
False positives are scoping problems, not reasons to remove armor. This flow is exactly how a production CMS false-positive gets resolved without ever dropping protection for public traffic.