Tuning the WAF without breaking your app

The hardest part of a web application firewall is not writing rules. It's rolling the rules out without breaking the applications you're protecting. This is the playbook our own reliability team uses whenever a customer — or our own platform — adopts a new managed ruleset.

Step 1: simulate before you block

Never flip a new ruleset straight to block. Deploy it in simulation mode first. Simulated rules log what they would have blocked, without touching real traffic. That gives you a baseline of "matches" to triage before anyone's page 500s.

gitflare rules waf add example.com \
  --expression 'any(managed:core-v8)' \
  --action simulate \
  --name "core-v8 trial"

Step 2: triage the noise

Leave simulation on for at least one full business cycle — usually a week. Then review the analytics security-events view and classify matches:

• Real attacks — SQLi, XSS, path traversal attempts. These should be blocks.
• Legitimate-but-odd traffic — admin tools, API clients with unusual headers. These need exceptions, not silence.
• False positives — normal users hitting a rule for the wrong reason. These need rule exceptions.

Most first-time adopters find 80% of matches fall into the first category. The remaining 20% decides your exception list.

Step 3: ship exceptions as rules, not as silence

The temptation is to disable the noisy rule outright. Resist it. Instead, write a precise exception that comes first in evaluation order:

# 1. exception — our marketing CMS posts rich HTML, allow it
gitflare rules waf add example.com \
  --expression 'http.request.uri.path contains "/cms" and http.request.method eq "POST"' \
  --action allow --priority 1

# 2. enforcement — everything else matches the managed set
gitflare rules waf add example.com \
  --expression 'any(managed:core-v8)' \
  --action block --priority 10

This way the exception is visible, reviewable, and attributable. When someone asks "why is the CMS exempt?", the answer is in version control — not in a mystery toggle.

Step 4: block in stages

When you do switch enforcement on, do it in stages: challenge for the first week, then block. A challenge gives suspicious traffic a lightweight proof-of-human check instead of a hard 403. It converts most accidental false positives into completed requests, while still stopping the automated stuff.

Step 5: keep a rollback plan

Every ruleset we ship has a versioned audit trail, and a one-command rollback if something goes sideways. Your custom rules should have the same property: keep them in a config repo, gate them behind a deploy pipeline, and know exactly which command undoes the last change.

# roll back the last enforcement change in one move
gitflare rules waf revert example.com --to 2026-04-20

The payoff

Following this sequence, a typical zone goes from zero coverage to enforced core-v8 in about three weeks, with zero user-facing incidents. That's the whole point of tuning: security you can actually keep on.