中文
devexamples
← Workflows

阅读中文版本

WAF Rule Tuning Workflow

Run the WAF in detection mode first, triage findings against real traffic, tune or allowlist confirmed false positives, and then enable blocking.

intermediate~90 minsecuritywafoperations

Objective

Enable WAF protection in blocking mode without breaking legitimate traffic.

Environment

  • A WAF with detection and blocking modes
  • Request logs to label findings

Steps

1. Enable the WAF in detection

Enable the WAF in detection or count mode.

Expected state: Findings are logged without blocking.

2. Triage findings to separate real attacks

Triage findings to separate real attacks from false positives.

Expected state: You know what needs tuning.

3. Tune rules or add narrowly scoped

Tune rules or add narrowly scoped exceptions for confirmed false positives.

Expected state: Legitimate traffic is unblocked.

4. Switch to blocking and monitor

Switch to blocking and monitor for missed attacks and new false positives.

Expected state: Protection is active and observed.

Decision points

Disable a noisy rule or add an exception?

  • Narrow exception
  • Disable the rule globally

Narrow exception keyed to the specific path and pattern; disabling globally removes real protection.

Exception without expiry?

  • With expiry and review
  • Permanent

Every exception should have an owner and a review date; permanent exceptions become forgotten holes.

Expected outcome

A WAF in blocking mode tuned against real traffic, with documented exceptions and ongoing monitoring.

Verification

Confirm the previously confirmed false positives no longer trigger and that known attack payloads are blocked.

Cleanup

Record rule set version, exceptions, and their justification with an expiry for review.

Overview

Enable WAF protection in blocking mode without breaking legitimate traffic. Confirm the previously confirmed false positives no longer trigger and that known attack payloads are blocked.

Steps

  1. Enable the WAF in detection or count mode. Expected state: Findings are logged without blocking.
  2. Triage findings to separate real attacks from false positives. Expected state: You know what needs tuning.
  3. Tune rules or add narrowly scoped exceptions for confirmed false positives. Expected state: Legitimate traffic is unblocked.
  4. Switch to blocking and monitor for missed attacks and new false positives. Expected state: Protection is active and observed.
curl -s "https://app.example.com/search?q=1%27+OR+1%3D1--" -o /dev/null -w "%{http_code}\n"
# should be blocked (403) once blocking mode is enabled

Verification

  • A WAF in blocking mode tuned against real traffic, with documented exceptions and ongoing monitoring.

Decision points

  • Disable a noisy rule or add an exception? Options: Narrow exception; Disable the rule globally. Recommended: Narrow exception keyed to the specific path and pattern; disabling globally removes real protection.
  • Exception without expiry? Options: With expiry and review; Permanent. Recommended: Every exception should have an owner and a review date; permanent exceptions become forgotten holes.