Skip to main content
Cloud & AI Hub
Browse
Glossary AI Directory Playgrounds Models Prompts Explainers Strategy Matrix Benchmark Decoder
intermediate 8 mins Read

How WAFs Detect and Block Exploits

How WAFs use signature matching, anomaly scoring, and ML-based behavioral analysis to detect SQLi, XSS, and SSRF at the edge.

Last reviewed: July 27, 2026

A WAF sits in front of a web application and inspects incoming HTTP requests against a rule set — pattern-matching for known attack signatures (SQL injection strings, script tags for XSS), enforcing rate limits, and increasingly scoring requests with anomaly-detection models — blocking or flagging requests before they reach the application. It operates at the HTTP layer, distinct from a network firewall that only inspects IP/port-level traffic.

Introduction

A Web Application Firewall (WAF) sits between the internet and your web application, inspecting HTTP/HTTPS requests before they reach your servers. Unlike network firewalls (which operate at Layer 3/4 on IP addresses and ports), WAFs operate at Layer 7 — they understand HTTP semantics, can decode URL encoding, parse JSON bodies, and detect attack patterns in request parameters, headers, and cookies. WAFs protect against the OWASP Top 10 attack classes including SQL injection, Cross-Site Scripting, and Server-Side Request Forgery.

Step-by-Step: How WAF Detection Works

flowchart TD
    A["1. Request Inspection Points"]
    B["2. Signature-Based Detection (Rule Sets)"]
    C["3. Anomaly Scoring (OWASP CRS Mode)"]
    D["4. AWS WAF Rule Configuration"]
    E["5. WAF Evasion Techniques and Limitations"]
    A --> B
    B --> C
    C --> D
    D --> E

Step 1: Request Inspection Points

Incoming HTTP request components inspected by WAF:
  URL path:    /admin/../../../etc/passwd  ← Path traversal
  Query params: ?id=1' OR '1'='1          ← SQL injection  
  Headers:     User-Agent: sqlmap/1.7     ← Scanner fingerprint
  Cookies:     session=<script>alert(1)   ← XSS in cookie
  Request body: {"email": "admin@x.com; DROP TABLE users--"} ← SQLi in JSON

Step 2: Signature-Based Detection (Rule Sets)

WAFs maintain databases of attack signatures — regex and pattern matching rules:

OWASP CRS (Core Rule Set) examples:

SQLi Detection:
  Pattern: (?i)(union.+select|select.+from)
  Matches: ?q=1 UNION SELECT username,password FROM users--

XSS Detection:
  Pattern: <script[^>]*>[sS]*?</script>
  Pattern: javascript:s*[a-z]  (in href/src attributes)
  Matches: ?name=<script>alert(document.cookie)</script>

Path Traversal:
  Pattern: ../|..\
  Matches: /app/../../../etc/passwd

Step 3: Anomaly Scoring (OWASP CRS Mode)

Rather than blocking on any single match (high false positive rate), OWASP CRS accumulates an anomaly score:

Request: ?id=1' OR SLEEP(5)--
  Match: SQL injection pattern  → +5 points
  Match: SQL function call      → +3 points
  Match: SQL comment syntax     → +2 points
  Total: 10 points → Exceeds threshold (default: 5) → BLOCK
  
Request: ?name=John%27s
  Match: Apostrophe in input    → +2 points
  Total: 2 points → Below threshold → ALLOW
  (Without scoring, the apostrophe would be a false positive block)

Step 4: AWS WAF Rule Configuration

resource "aws_wafv2_web_acl" "main" {
  name  = "production-waf"
  scope = "REGIONAL"

  default_action { allow {} }

  # AWS Managed Rules — pre-built protections
  rule {
    name     = "AWSManagedRulesCommonRuleSet"
    priority = 1
    override_action { none {} }
    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesCommonRuleSet"
        vendor_name = "AWS"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "CommonRuleSet"
      sampled_requests_enabled   = true
    }
  }

  # Custom rate-based rule
  rule {
    name     = "RateLimitPerIP"
    priority = 2
    action { block {} }
    statement {
      rate_based_statement {
        limit              = 2000  # requests per 5 minutes
        aggregate_key_type = "IP"
      }
    }
    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "RateLimit"
      sampled_requests_enabled   = true
    }
  }
}

Step 5: WAF Evasion Techniques and Limitations

WAFs can be bypassed through encoding tricks — which is why they’re defense-in-depth, not a complete solution:

SQL injection bypass examples:
  Standard:   ' OR 1=1--
  URL encoded: %27%20OR%201%3D1--
  Double URL:  %2527%2520OR%25201%253D1--
  Case mixing: ' Or 1=1--
  Comments:   '/**/OR/**/1=1--
  
Defense: WAFs should decode multiple encoding layers before matching
Best practice: WAF + parameterized queries (never rely on WAF alone for SQLi protection)

Key Takeaways

  • WAFs inspect Layer 7 HTTP content — URL paths, query parameters, headers, cookies, and request bodies — unlike network firewalls which only see IP/ports.
  • Anomaly scoring (OWASP CRS) accumulates points across multiple partial matches, reducing false positives vs. single-pattern blocking.
  • AWS Managed Rule Groups provide maintained, regularly updated protection against OWASP Top 10 without writing custom rules.
  • WAFs can be evaded with encoding tricks — they are defense-in-depth, not a substitute for secure coding practices like parameterized queries and output encoding.
  • Run WAFs in count mode before enforcement mode to measure false positive rate against your production traffic.

Common questions

Can a WAF replace secure coding practices?

No — a WAF is a compensating control, not a substitute for fixing vulnerabilities. Signature-based rules miss novel attack patterns and can be bypassed with encoding tricks; the OWASP Top 10 exists precisely because these vulnerability classes need to be fixed in the application itself.

Why do WAFs generate false positives?

Pattern-based rules that catch SQL injection attempts can also match legitimate input that happens to contain similar syntax — a user genuinely typing `SELECT` in a support ticket, for example. Tuning rule sensitivity against real application traffic is an ongoing operational task, not a one-time setup.

Where does a WAF typically run?

At the edge, in front of the application — as a CDN feature (Cloudflare, Fastly), a cloud load balancer add-on (AWS WAF on an Application Load Balancer or CloudFront), or a reverse proxy — so malicious requests are filtered before they consume application resources.

Historical figures, architectures, and capabilities are for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Research papers, developer documentation.