WAF Rules: Writing Effective Web Application Firewall Policies

What Are WAF Rules?

A Web Application Firewall (WAF) inspects HTTP/SSL/TLS проверку traffic between users and your web application, blocking malicious requests based on a set of rules. WAF rules define what traffic patterns to look for and what action to take — allow, block, log, or challenge with a CAPTCHA.

Unlike network firewalls that operate at the IP/port level (Layer 3/4), WAFs operate at the application layer (Layer 7). They can inspect URL paths, query parameters, POST bodies, headers, cookies, and even JSON/XML payloads. This makes them effective against application-specific attacks that network firewalls cannot detect.

Types of WAF Rules

Managed Rule Sets

Pre-built rules maintained by security vendors or the community. These cover known attack patterns:

• OWASP Core Rule Set (CRS) — the most widely used open-source rule set, covering SQL injection, XSS, command injection, path traversal, and more. Used by ModSecurity, AWS WAF, Cloudflare, and others
• Vendor-managed rules — Cloudflare Managed Rules, AWS Managed Rules, Akamai Kona — continuously updated by security teams
• Bot management rules — identify and block automated traffic, scrapers, and credential stuffing attacks

Custom Rules

Rules you write for your specific application. More precise than managed rules because they understand your application's expected behavior:

# ModSecurity custom rule: block requests to admin panel from non-whitelisted IPs
SecRule REMOTE_ADDR "!@ipMatch 10.0.0.0/8,203.0.113.50" \
    "id:1001,phase:1,deny,status:403,\
     chain"
SecRule REQUEST_URI "@beginsWith /admin" \
    "msg:'Admin access from non-whitelisted IP'"

# Block requests with SQL injection patterns in query string
SecRule ARGS "@detectSQLi" \
    "id:1002,phase:2,deny,status:403,\
     msg:'SQL Injection attempt detected'"

Rate-Based Rules

Limit the number of requests from a single source within a time window:

# Cloudflare rate limiting rule (conceptual)
If: requests from same IP to /api/login > 10 per minute
Then: block for 600 seconds

# AWS WAF rate-based rule
{
  "Name": "LoginRateLimit",
  "Priority": 1,
  "Action": { "Block": {} },
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "AggregateKeyType": "IP"
    }
  }
}

Common Attack Patterns and Rules

SQL Injection (SQLi)

Attacks inject SQL code through user input to manipulate database queries:

# Block common SQL injection patterns
SecRule ARGS|ARGS_NAMES|REQUEST_COOKIES \
    "@detectSQLi" \
    "id:2001,phase:2,deny,status:403,\
     msg:'SQL Injection detected',\
     tag:'attack-sqli'"

# Specific patterns to watch for:
# ' OR 1=1 --
# UNION SELECT
# ; DROP TABLE
# ' AND (SELECT ...

Cross-Site Scripting (XSS)

# Block XSS patterns in parameters and headers
SecRule ARGS|REQUEST_HEADERS \
    "@detectXSS" \
    "id:2002,phase:2,deny,status:403,\
     msg:'XSS attack detected',\
     tag:'attack-xss'"

# Watch for: <script>, javascript:, onerror=, onload=

Path Traversal

# Block directory traversal attempts
SecRule REQUEST_URI|ARGS "@contains ../" \
    "id:2003,phase:1,deny,status:403,\
     msg:'Path traversal attempt'"

Remote Code Execution

# Block common command injection patterns
SecRule ARGS "@rx (?:;|\||&&)\s*(?:cat|ls|whoami|id|uname|wget|curl)" \
    "id:2004,phase:2,deny,status:403,\
     msg:'Command injection attempt'"

Writing Effective Custom Rules

Principles for writing rules that catch attacks without blocking legitimate traffic:

• Start in detection mode — log matches without blocking. Analyze logs for false positives before enforcing. ModSecurity calls this SecRuleEngine DetectionOnly
• Be specific about scope — apply rules only to relevant parameters. A SQL injection rule on a search field makes sense; on a rich text editor field, it will cause false positives
• Use anomaly scoring — instead of blocking on any single rule match, accumulate a score across multiple rules. Block when the total score exceeds a threshold. The OWASP CRS uses this approach
• Whitelist before blacklist — define what valid requests look like (allowed characters, expected formats, value ranges) rather than trying to enumerate all attack patterns
• Test with real traffic — replay production traffic (anonymized) against new rules before deploying

Handling False Positives

False positives — legitimate requests blocked by WAF rules — are the biggest operational challenge. Strategies:

• Rule exclusions — disable specific rules for specific parameters. Example: disable SQLi detection for the content parameter on /api/articles (where HTML content is expected)
• Anomaly threshold tuning — raise the anomaly score threshold to require more rule matches before blocking
• Whitelisting — allow known-good IPs, user agents, or request patterns to bypass specific rules
• Progressive enforcement — start with logging, move to CAPTCHA challenge, then to blocking as confidence grows

# Exclude SQL injection rule for CMS content fields
SecRule REQUEST_URI "@beginsWith /api/articles" \
    "id:3001,phase:1,nolog,pass,\
     ctl:ruleRemoveTargetById=942100;ARGS:content"

WAF Deployment Models

Monitoring WAF Performance

• Blocked request rate — sudden spikes indicate attacks or new false positives after rule changes
• False positive rate — track customer complaints and support tickets that correlate with WAF blocks
• Rule trigger frequency — identify rules that fire most often. High-frequency rules may need tuning
• Latency impact — WAF inspection adds processing time. Monitor P95 latency with and without WAF
• Bypass attempts — look for patterns that suggest attackers are probing for rule gaps

Conclusion

WAF rules are your application's first line of defense against web attacks. Start with managed rule sets (OWASP CRS) for baseline protection, then add custom rules for application-specific threats. Always test in detection mode first, handle false positives systematically, and monitor rule effectiveness continuously. A well-tuned WAF blocks thousands of attacks daily while remaining invisible to legitimate users. Combine with monitoring tools like Enterno.io to verify your WAF is not inadvertently blocking legitimate traffic or degrading performance.