A WAF that blocks one legitimate checkout per thousand sounds accurate until you multiply it by your traffic. False positives are not background noise to live with; they are a measurable engineering problem with a repeatable fix loop: rank rules by friction, classify each match, scope the change, and pin the result with a regression test so the same fight never happens twice.
The cost of a false positive
A blocked attack costs the attacker a retry. A blocked customer costs you the order, sometimes the account, and — because most users never report a block page — the failure is nearly invisible unless you go looking. That asymmetry sets the tuning priority: measure friction where it costs money first. Pull blocked-request counts by rule and join them against your critical paths — login, checkout, search, the API endpoints your mobile app calls. A rule blocking 40 requests a day on /checkout outranks a rule blocking 4,000 a day on a path only scanners visit.
Build the friction report
The working document is a table: rule ID, action, matches per day, top matched paths, top client identifiers, and a sample of the actual matched payloads. Every WAF exposes enough logging to build it — sampled firewall events, count-mode logs, or full request logging to your SIEM — and the sample payloads matter more than the counts, because a rule ID alone tells you what the rule suspects, not what your traffic actually contained. Sort by matches-on-critical-paths descending and work the list top down. Most teams find the pain concentrates in fewer than ten rules; the OWASP Core Rule Set’s own documentation acknowledges that higher paranoia levels trade precision for recall, which is why the same handful of injection and protocol-violation rules dominate every friction report.
Classify: attack, noise or application quirk
For each high-friction rule, read the payloads and sort matches into three buckets. Genuine attacks stay blocked — that is the WAF doing its job, and a rule that catches real attacks alongside false positives needs a narrower fix, never a disable. Noise is traffic that is neither attack nor customer: broken bots, ancient clients, malformed retries; blocking it is usually harmless but inflates every metric, so consider a separate rate-limit or bot rule instead. Application quirks are the expensive bucket: your own software legitimately sending things that look hostile — markup in form fields, serialized blobs in cookies, SQL-ish filter syntax in query strings. Each quirk gets a decision: change the application, or except the rule.
Scope the fix: threshold, exception or rewrite
Anomaly-scoring engines give you a global lever — raise the blocking threshold — but it weakens everything at once, so prefer it only when matches are diffuse and low-risk. The default tool is the scoped exception: skip this rule for this path and, where supported, only for the named parameter. On a cookie-triggered rule, except the cookie name, not the URL, or the exception silently covers every path the cookie rides on. The best fix is still the application rewrite: moving a rich-text field from raw HTML to a structured format removes the false positive and an actual injection surface in one change. Whichever you choose, record rule, scope, evidence and owner — our notes on WAF tuning defaults cover what a healthy exception register looks like.
Regression tests and the quarterly re-tune
Pin every fix with two tests: a replay of the legitimate request that used to be blocked (must pass) and a representative attack payload for the same rule (must still be blocked). Run the suite after every ruleset update and platform migration — managed rules change under you, and an update that re-breaks checkout should fail a pipeline, not a customer. A methodology for building that suite is in our piece on WAF testing. Then put a quarterly re-tune on the calendar: re-pull the friction report, retire exceptions whose application quirk has been fixed, and check that the top-ten friction rules are still the ones you think they are. Tuning is not a project you finish; it is a loop you keep cheap. If you are still in log-only mode, start with the safe WAF rollout sequence first.