Tune WAF Rules to Reduce False Positives

A WAF that blocks legitimate traffic gets turned off — and a WAF that's off protects nothing. The skill is tuning: stop the false positives without opening a hole that lets real attacks through. In this exercise you'll tune the rule set for Riverton Retail, whose managed WAF is blocking two legitimate flows. First reason through two tuning decisions, then author the corrected, ordered rule list.

The situation

Riverton's WAF runs the vendor's managed OWASP rule set in blocking mode. Two problems have surfaced:

The SQL-injection managed rule is firing on the public /search endpoint, because customers' search queries sometimes contain words like select or or. Legitimate searches are being blocked.
A partner batch integration from 203.0.113.10 is hitting the rate limit and getting blocked, breaking a scheduled data feed.

Meanwhile the XSS and path-traversal managed rules have produced zero false positives. The challenge: fix the two false positives while keeping real SQLi, XSS, and path-traversal attacks blocked everywhere else.

Decision 1: How do you fix the SQLi false positive?

Quick check

The SQLi managed rule blocks legitimate searches on /search. What is the right tuning move?

Disable the SQLi managed rule entirely so searches work

Add a narrowly-scoped exception that allows the /search endpoint's q parameter past the SQLi rule, while keeping the SQLi rule active on every other path and parameter

Turn the whole WAF to monitor mode so nothing is blocked

Tell customers not to use SQL keywords in their searches

Decision 2: Where must the partner allowlist sit in the rule order?

Quick check

You add an allow rule for the partner IP 203.0.113.10 so its batch job isn't rate-limited. WAF rules are evaluated in order, top to bottom, first match wins. Where must the allow rule go?

It does not matter where the allow rule sits; the WAF figures it out

The partner allow rule must come BEFORE the rate-limit and broad block rules, so the partner traffic is matched and allowed before the rate limiter or managed rules can block it

Put the allow rule last so the security rules get first priority

Put the allow rule anywhere but set it to monitor mode

Build it: the tuned rule list

Author the corrected WAF rule set as an ordered list (it's evaluated top to bottom, first match wins). Put your scoped allow exceptions first, then the managed blocking rules you're keeping. For each rule, give the match condition (e.g. ip:203.0.113.10, uri:/search AND param:q, managed:SQLi), the protected resource, the action (allow or block), and the rationale.

Exercise

~15 min

Tune Riverton Retail's WAF: stop the false positives, keep the protection

Scenario

WAF blocking legitimate traffic at Riverton Retail

Tune the managed WAF rule set so the two false positives stop, while real SQLi, XSS, and path-traversal attacks stay blocked everywhere else. Remember: rules evaluate top to bottom, first match wins — so scoped allow exceptions must come before the broad block rules.

The SQLi managed rule fires on the public /search endpoint's q parameter (legitimate searches)
A partner batch job from 203.0.113.10 is being rate-limited and blocked
The XSS and path-traversal managed rules have ZERO false positives — keep them as-is
Order matters: allow exceptions must precede the rules they bypass

Write 3–6 rules. For each: set the match condition, the protected path, and whether to allow or block, and explain why the rule exists.

Rule 1

Action

Match condition

Protected path

Rule 2

Action

Match condition

Protected path

Rule 3

Action

Match condition

Protected path

Rule order (evaluated top → bottom)

0 allow · 0 block

Add match conditions to see the ordered rule list.

What to carry forward

WAF tuning is a discipline of narrow exceptions in the right order, never wholesale disabling. You fix a false positive by scoping an allow to the exact path, parameter, or IP that's safe — leaving the rule blocking everywhere else — and you place that allow above the rules it's meant to bypass, because first-match-wins makes ordering a control. The clean rules you leave untouched. The anti-patterns this exercise inoculates against are the ones that show up in real findings: a managed rule globally disabled to fix one endpoint, a WAF quietly flipped to monitor mode, or an allowlist buried below the block rules so it never takes effect. Evidence is the rule configuration plus the WAF logs showing the false positives stopped and real attacks still blocked.

That closes Phase 5: you can now read and design the network boundary (VPC, subnets, security groups), the per-application access layer (ZTNA), and the application-facing protections (WAF, DDoS, service mesh) — and, in every case, name the evidence that proves the control operates. Next phase: API Security.