Web Application Firewall Engineering

A Web Application Firewall (WAF) inspects HTTP traffic and blocks malicious requests before they reach your application. But an untuned WAF is worse than no WAF — it blocks legitimate users, creates false sense of security with default rules, and generates thousands of alerts that nobody reads.

---

WAF Architecture

                    Internet
                       │
                ┌──────┴──────┐
                │     CDN     │  (CloudFlare, AWS CloudFront)
                │   + WAF     │  ← First line of defense
                └──────┬──────┘
                       │ Clean traffic only
                ┌──────┴──────┐
                │   Load      │
                │   Balancer  │
                └──────┬──────┘
                       │
                ┌──────┴──────┐
                │ Application │
                │ Servers     │
                └─────────────┘

WAF inspects:
  ☐ Request headers (Host, User-Agent, cookies)
  ☐ URL path and query parameters
  ☐ Request body (POST data, JSON, XML)
  ☐ Response headers and body (data leak prevention)

---

Rule Categories

# Core rule sets (OWASP CRS equivalent)
rule_sets:
  sql_injection:
    description: "Detect SQL injection attempts"
    examples:
      - "' OR 1=1 --"
      - "'; DROP TABLE users; --"
      - "UNION SELECT * FROM passwords"
    action: BLOCK
    
  xss:
    description: "Detect cross-site scripting"
    examples:
      - "<script>alert('xss')</script>"
      - "javascript:void(0)"
      - "onerror=alert(1)"
    action: BLOCK
    
  path_traversal:
    description: "Detect directory traversal"
    examples:
      - "../../etc/passwd"
      - "..\\windows\\system32"
    action: BLOCK
    
  rate_limiting:
    description: "Throttle excessive requests"
    rules:
      - path: "/api/login"
        limit: "10 requests per minute per IP"
        action: BLOCK_429
      - path: "/api/*"
        limit: "1000 requests per minute per IP"
        action: BLOCK_429
    
  bot_detection:
    description: "Identify and manage bot traffic"
    signals:
      - missing_javascript: "Cannot execute JS challenges"
      - known_bot_ua: "Match against known bot signatures"
      - behavioral: "Abnormal request patterns"
    action: CHALLENGE  # CAPTCHA or JS challenge

---

CloudFlare WAF Configuration

# Custom WAF rules via CloudFlare API
class WAFRuleManager:
    def create_rate_limit_rule(self):
        """Rate limit login endpoint to prevent brute force."""
        return self.cf.create_rule({
            "description": "Rate limit login attempts",
            "expression": '(http.request.uri.path eq "/api/auth/login" and http.request.method eq "POST")',
            "action": "block",
            "ratelimit": {
                "characteristics": ["ip.src"],
                "period": 60,
                "requests_per_period": 10,
                "mitigation_timeout": 600,  # Block for 10 minutes
            }
        })
    
    def create_geo_blocking_rule(self):
        """Block traffic from high-risk regions."""
        return self.cf.create_rule({
            "description": "Geo-block high-risk countries",
            "expression": '(ip.geoip.country in {"RU" "CN" "KP"} and not cf.bot_management.verified_bot)',
            "action": "managed_challenge",
        })
    
    def create_api_protection_rule(self):
        """Protect API endpoints with schema validation."""
        return self.cf.create_rule({
            "description": "Block oversized API requests",
            "expression": '(http.request.uri.path matches "^/api/.*" and http.request.body.size gt 1048576)',
            "action": "block",
        })

---

False Positive Management

False Positive Workflow:
  1. WAF blocks legitimate request
  2. User reports issue or monitoring detects
  3. Identify which rule triggered
  4. Analyze: Is this a true false positive?
  
  If yes:
    a. Create exception rule for specific path/parameter
    b. Document why exception was made
    c. Set review date (quarterly)
  
  If no:
    a. Application has a vulnerability
    b. Fix the application code
    c. Keep the WAF rule active

Common false positives:
  - Rich text editors (HTML in POST body → XSS rule)
  - API endpoints accepting SQL-like syntax
  - File upload paths (path traversal patterns)
  - Legitimate long URLs (buffer overflow rules)

---

Anti-Patterns

Anti-Pattern	Consequence	Fix
Default rules, never tuned	False positives block users	Tune rules per application behavior
WAF as only security layer	SQL injection in internal APIs	Defense in depth: WAF + input validation + parameterized queries
Block mode from day one	Immediately blocks legitimate traffic	Start in detect mode, tune, then block
No logging/monitoring	Cannot investigate incidents	Log all WAF decisions, dashboard key metrics
Static threat intelligence	Miss new attack patterns	Subscribe to updated rule sets, review quarterly

A WAF is a filter, not a fix. It buys you time by blocking known attack patterns, but it cannot replace secure coding practices, input validation, and parameterized queries.