How long should I run a new custom rule in Log mode before blocking?

Don't go by time alone — go by traffic volume and diversity. We recommend a minimum of 72 hours including at least one full business cycle and 2-5 million sampled requests. For low-traffic endpoints (under 10k requests/day), you’ll need a full 7-14 days. You’re looking for a stable false positive rate below 0.02% and at least 50 true positive matches that you’ve manually verified. If you promote after 2 hours on a Monday morning, you haven’t seen weekend bot traffic or your nightly batch jobs yet.

Should I use regex or exact string matches for payload detection?

Start with exact matches and substring operators — they’re 4-10x faster at the edge and far easier to audit. Regex is powerful but expensive; a single poorly anchored .* can add 0.8-2ms of latency per request. When you do need regex, anchor it tightly to a specific field like http.request.uri.query and avoid greedy quantifiers. We see the best balance with a hybrid: use contains for the initial filter, then a narrow regex for validation only on that subset.

My rule works in testing but blocks our internal monitoring — how do I fix it?

You’re missing an allowlist for trusted automation. Don’t allowlist by IP alone — IPs rotate. Combine signals: allowlist by ASN + verified bot flag + a custom header or mTLS certificate + JA3 fingerprint if available. For example, exclude your Datadog or Checkly probes with not (ip.src in $monitoring_ips and http.request.headers["x-monitor-token"] eq "expected-secret"). That way you don’t accidentally create a bypass for attackers spoofing a single header.

What's the single biggest indicator a custom rule will cause false positives?

If your rule inspects http.request.body.raw or the entire URI without a path/method anchor, it will almost certainly false positive. Broad scope is the #1 predictor. The second is missing client reputation — rules that don’t check bot score, threat score, or rate history will treat your best customers and your worst attackers the same. If your rule has neither an endpoint anchor nor a client filter, rewrite it before you deploy.

WAF Custom Rule Authoring: Writing Effective Detection Rules Without False Positives

About six years ago I pushed a custom WAF rule that was meant to block SQL injection probes on a checkout API. It worked perfectly in staging, but an hour after it went live in enforce mode, our support channel lit up — every customer with an apostrophe in their last name, like O'Brien, was getting a 403. We’d written a regex that was technically correct but context-blind, and we hadn’t measured its blast radius. That night taught me that writing detection rules isn’t about catching attackers, it’s about not catching everyone else.

Why Most Custom Rules Die in the First 48 Hours

When teams start with WAF Managed Ruleset Comparison: OWASP CRS, Commercial, and Provider-Specific Rules, they often assume custom rules are just smaller versions of managed ones. They aren’t. Managed rulesets have thousands of hours of tuning and paranoia baked in; your custom rule has you, a Jira ticket, and maybe 30 minutes before the next deployment. The most common failure I’ve seen isn’t a missed attack, it’s a rule that’s far too greedy. Someone writes `(?i)(union.*select|or\s+1=1)` and applies it to `REQUEST_URI`, `ARGS`, `BODY`, and `HEADERS` all at once, without considering where that payload actually matters.

That kind of broad matching is what kills you. I’ve reviewed rules that flagged marketing UTM parameters, base64-encoded images, and even legitimate JSON fields because the author didn’t anchor the inspection to a specific location. If you’re trying to protect a login endpoint, you don’t need to inspect every single query string on your static asset CDN. You need to ask: where does this attack have to appear to be dangerous, and where would a normal user never put it? The more precisely you can answer that, the fewer false positives you’ll create. We’ve learned to start every rule draft by documenting the attack vector’s required context — method, path, content-type, and parameter name — before we write a single line of regex.

Understanding how your platform actually evaluates rules helps you write tighter logic. Not all engines normalize, decode, or parse the same way. A rule that looks for `../` won’t fire if the engine already normalized the path, and a rule that looks for `