WAF Rule Configuration Guide: Building an Effective Web Protection System

A WAF (Web Application Firewall) stands at the front door of your web application, keeping malicious traffic away from business logic. It is a core component of web application security. But "installed a WAF" and "tuned a WAF" are two different things — rules that are too loose are useless, and rules that are too strict kill legitimate users and crawlers alike. A good rule set finds the balance between security coverage and business availability.

1. WAF rule types

Rule type Description Example
Blacklist Match known attack signatures and block SQL injection, XSS patterns
Whitelist Allow only specified patterns, deny everything else Admin panel IP whitelist
Rate limiting Cap request frequency per IP/session Login endpoint: 5/minute
Behavioral Model request behavior to detect anomalies Crawler detection, credential stuffing
Rule exception Exempt legitimate scenarios Rich-text editor allowed specific HTML

2. OWASP CRS: battle-tested rules out of the box

The OWASP Core Rule Set is the industry standard for open source WAF rules, covering SQL injection, XSS, path traversal, command injection, and more. Loading CRS into ModSecurity gives you baseline protection:

# Include the CRS init config before the rules
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

# A sample CRS rule: detect XSS
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES \
  "/((\%3C)|<)[^]+((\%3E)|>)/" \
  "phase:2,deny,t:none,t:normalisePath,msg:'Cross-site Scripting (XSS) Attack'"

# Path traversal detection
SecRule REQUEST_URI|ARGS|REQUEST_HEADERS \
  "@rx /etc/passwd" \
  "phase:2,deny,t:none,msg:'Path Traversal Attack'"

CRS ships with PARANOIA levels (1-4) to control strictness: level 1 fits most sites with low false-positive rates; level 4 suits finance and government workloads with high security demands — but it needs a lot of exception rules to keep business running.

Reference: OWASP CRS official repository https://github.com/coreruleset/coreruleset; ModSecurity documentation https://modsecurity.org/

3. Cloudflare WAF configuration example

Managed WAFs like Cloudflare use expression-based rules:

# Block brute-force POSTs to wp-admin (excluding the office subnet)
Rule Name: Block wp-admin brute force
Expression: http.request.uri.path contains "wp-admin"
            and http.request.method in {"POST"}
            and not ip.src in {192.0.2.0/24}
Action: Block

# Rate limit API endpoints
Rule Name: Rate Limit API
Expression: http.request.uri.path starts with "/api/"
            and http.request.method in {"POST"}
Action: Managed Challenge
Rate Limit: 100 requests/10 minutes

The power here is in combining conditions: looking at the path alone or the method alone causes false positives, but when you combine source subnet, method, path, and frequency, you hit the attack precisely without collateral damage.

4. Handling false positives

False positive type Solution
IP wrongly blocked Add to whitelist or raise the rate threshold
Legitimate parameter misjudged Create a rule exception for that parameter (e.g., rich-text HTML)
Normal behavior misjudged Lower rule sensitivity or switch to PARANOIA 1
Specific business scenario Create a dedicated exclusion rule scoped to URI + conditions

The principle is "minimal exemption": if you can target a single URI, don't open up the whole path; if you can add IP/method conditions, don't exempt the entire site — otherwise the exemption itself becomes a new attack surface.

Here's a concrete example: a back-office rich-text editor stores <svg> tags verbatim when images are uploaded, and CRS's XSS rules happen to block <svg>-related patterns, so legitimate saves fail. The fix isn't to disable the whole XSS rule — it's to allow requests to /admin/editor/save that carry the rich-text field content, and keep everything else strict. The editor keeps working without opening a backdoor for attackers.

Another point people miss is rule evaluation order: managed WAFs typically evaluate rules as "whitelist → exceptions → rate limits → blacklist"; if an exception rule sits behind the blacklist it may never fire. Before configuring, find out the evaluation order on your platform, or you'll write exceptions that silently do nothing.

5. Best practices

  1. Log before blocking: run new rules in log/detection mode for 1-2 weeks, confirm no false positives, then switch to blocking.
  2. Make updates routine: CRS releases updates monthly — subscribe to the changelog and run regression tests regularly.
  3. Monitor and review: periodically review top blocked attacks and false-positive trends in WAF logs, and fold newly observed attack techniques into custom rules.
  4. Defense in depth: a WAF is only the first layer — combine it with CDN rate limiting, IP reputation feeds, geolocation, and application-level parameter validation for far better results than piling on rules in one place.

6. A real-world case

An e-commerce site faced credential stuffing on its login endpoint during a sales season: attackers rotated IPs through a proxy pool to evade simple per-IP rate limits. The fix combined three layers:

  1. WAF layer: rate-limit /api/login (20 requests per IP per 10 minutes) plus challenge common proxy IP ranges;
  2. Application layer: add CAPTCHA and account lockout policies;
  3. Data layer: monitor failed-login counts per IP range and trigger risk controls.

After rollout, brute-force attempts dropped by more than 95% while legitimate login success was barely affected.

16IDC Takeaway

WAF rule configuration is tuning, not installing. Treat every rule as a small experiment: log the change, watch for false positives, and evaluate blocking quality. Your rule set will grow to fit your business instead of staying at "default config" forever.