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.