Debugging WAF False Positives

2026-08-30

Problem

A legitimate, correctly authenticated API request is being blocked by the WAF. The client team sees it as "the API is broken," while the security team sees nothing that looks like an obvious attack in the blocked payload.

Symptoms

A specific endpoint, or a specific field in a POST body, reliably triggers a block while nearly identical requests succeed
The blocked requests come from a known, legitimate source — an internal service or a partner integration — rather than obviously abusive traffic
The failure is a firewall/WAF block response, not an application error — the request never reaches the origin at all

Observed

The Security Events log showed the request was blocked by a managed ruleset rule, not a custom rule, with a description referencing SQL injection or command injection signatures
The specific field value that triggered the match was a legitimate string that happened to contain characters or keywords the rule pattern-matches on, such as a free-text comment field containing something that looked like SQL syntax
Only one specific managed rule ID was responsible; other requests to the same endpoint with different field values passed through the same ruleset without issue

Root cause (working theory)

We believe this is a true false positive from a managed ruleset's generic pattern-matching, not a misconfigured custom rule. Managed WAF rulesets are tuned broadly across many customers' traffic and can't know that a specific field in a specific application is expected to contain content that resembles an attack signature. This is the most common shape of WAF false positive we've seen: a legitimate but attack-pattern-shaped value in a single field, not a broken rule or a real attack.

Why the obvious fix failed

The instinctive fix is often to disable the WAF, or the entire managed ruleset, for the affected endpoint. That does stop the block, but it also removes real protection for that endpoint against everything else the ruleset would have caught — a much bigger tradeoff than the actual problem requires.

Fix

Add a scoped WAF exception that only skips the specific rule ID for the specific endpoint and field pattern involved, rather than disabling the ruleset broadly. Most WAF dashboards support skipping a specific managed rule ID for a match expression scoped narrowly to the affected path.

Verify

Re-send the exact request payload that was previously blocked and confirm it now reaches the origin and succeeds. Separately, send an actually malicious payload against the same endpoint and confirm the ruleset still blocks it, to confirm the exception is scoped narrowly and didn't disable more than intended.

Takeaway

Before disabling a WAF ruleset over a false positive, check the Security Events log for the specific rule ID and scope an exception to exactly that rule and endpoint. A narrow, rule-ID-specific skip preserves the rest of the ruleset's protection instead of trading it all away for one endpoint's false positive.