Taming WAF false positives — tuning OWASP rules without breaking your app

The real reason WAFs get switched off

Ask why a team disabled their web application firewall and the answer is almost never “it missed an attack.” It is “it blocked our checkout” or “it broke the admin panel” or “support was drowning in tickets from customers who couldn’t submit a form.” A WAF that blocks real users is worse than useless — it trains everyone to distrust it, and eventually someone flips it to log-only and forgets. The security control that generates the most false alarms is the one that gets abandoned first.

So the practical question is not “how strict can the rules be” but “how do you keep strong protection without collateral damage.” That is a tuning problem, and it has a real answer.

Why the OWASP ruleset scores instead of blocking outright

A naive rule engine blocks on the first matching rule. That is a false-positive factory, because plenty of perfectly legitimate content looks a little like an attack — a blog post that quotes a SQL snippet, a form field that accepts markup, a search query with special characters. The OWASP Core Rule Set our dual signature WAF engines run does not work that way. It uses anomaly scoring: each matching rule adds to a score, and a request is only blocked when the accumulated score crosses a threshold. A single borderline match does not block anything; it takes a genuine cluster of suspicious signals.

That single design choice removes most of the naive false positives before you tune anything. A legitimate request that trips one rule sails through; an attack that trips five is stopped.

Tuning is per-site, and it is reversible

Anomaly scoring gives you one dial that matters: the threshold. Because every site is multi-tenant-isolated with its own configuration, you tune that threshold — and any specific rule exclusions — for your application without touching anyone else’s. A site that legitimately handles code snippets can loosen the rules that fire on code-like input; a bare brochure site can run tight. There is no shared global config where one tenant’s exception weakens another’s protection.

The workflow that keeps this safe:

• Start in detection, not enforcement. Run the rules scoring-only first and watch what would have been blocked against real traffic. The challenge ladder also gives you a middle option — challenge a borderline request instead of blocking it — so tuning is not a binary between “allow” and “reject.”
• Read the audit trail. Every decision is recorded in an immutable append-only log with the rules that matched, so a false positive is a specific, diagnosable event — this rule, this request, this score — not a mystery block you have to reproduce blind.
• Adjust the specific rule, keep the rest. You exclude or re-weight the one rule causing the problem, not the whole category, so tuning out a false positive costs you almost none of your coverage.

What we don’t claim

There is no threshold that gives you zero false positives and zero false negatives at the same time — that trade-off is real and we will not pretend a setting makes it disappear. Tuning moves the balance to the right place for your app; it does not abolish the balance. We also do not auto-tune your thresholds silently behind your back and hope for the best; the changes are yours, visible, and reversible, with the audit trail to show what each one did. And it all runs inline within our ≤5 ms design budget, so tuning for accuracy never costs you latency.

Getting the balance right

If your WAF is currently off because it was breaking things, that is a tuning failure, not a reason to run unprotected. Tell us your domain and we will start in detection mode and tune it against your real traffic before anything blocks.