Many web application firewalls do not block on the first suspicious match. They add points from every rule that fires and block when the total reaches a threshold. The OWASP Core Rule Set works this way, with a default inbound threshold of 5. That design lets you start by watching traffic, then block once false positives are tuned.
The scoring model
In the Core Rule Set documentation, each matching rule adds to an anomaly score based on severity. The default scores are Critical 5, Error 4, Warning 3 and Notice 2, and a configuration rule can override them.
After the request rules run, the transaction is denied if its score is greater than or equal to the inbound threshold. The documentation says the CRS should aim for an inbound threshold of 5 and lists the outbound default as 4. After response rules run, a response whose score meets or exceeds the outbound threshold is withheld, while the backend has still handled the request.
So with the default of 5, one Critical match blocks alone. Several lower severity matches can add up to a block as well.
An early blocking option adds checks after the first and third phases. It is disabled by default.
Why scoring exists
Single rule blocking makes every false positive a hard failure. Scoring lets many weak signals combine, and lets you choose how strict to be by moving the threshold. It also gives you data: the score is logged even when nothing is blocked.
A safe rollout path
- Observe first. Run the engine in a mode that logs but does not block. Many engines call this detection only. Check your engine's documentation for the exact setting, since names differ.
- Collect a representative period. Include your busiest days and your admin and API paths.
- Review what scored. Sort by rule and path. Real attacks look different from your own app posting HTML or JSON that resembles an attack.
- Add narrow exclusions. Exclude a specific rule for a specific path or parameter, not a whole rule everywhere.
- Turn on blocking. Keep the threshold at the default until exclusions are stable.
- Keep logging. Alert on repeated high scores from one source.
Paranoia levels
CRS also has paranoia levels that enable stricter rules at the cost of more false positives. The exact levels and defaults vary by version, so check the CRS documentation for the version you run before changing them.
What a WAF does not do
A WAF inspects requests and sometimes responses against patterns. It does not fix the bug in your code, and it cannot see what happens inside your application after a request passes. Our post on runtime guardrails covers that gap. The Cloudflare outage lessons post is a reminder that WAF rule changes should be rolled out gradually too.
Where Safeguard fits
Safeguard does not replace a WAF. It finds vulnerable dependencies, checks reachability and can open fix pull requests, which is how you remove the underlying bug. Autonomous remediation is off by default. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
With a default inbound threshold of 5, what blocks a request?
A total score of 5 or more, for example one Critical match, or several lower severity matches that add up.
Sources
Last reviewed: 19 October 2026.
