CDN WAF: Edge Security Rules
WAF at the CDN Edge
A Web Application Firewall inspects HTTP requests for malicious patterns and blocks attacks before they reach your origin. Running the WAF at the CDN edge means attacks are stopped at the nearest PoP — your origin never sees the malicious traffic. For foundational context, read CDN DDoS Protection: How CDNs Absorb Volumetric Attacks — FlyFish NWA.
How CDN WAFs Work
- HTTP request arrives at the CDN edge
- WAF engine evaluates the request against a rule set
- Each rule produces a score or match result
- If the aggregate score exceeds a threshold, or a critical rule matches, the request is blocked
- Clean requests are passed to cache lookup or origin
Processing time: typically 0.1-2ms per request — negligible added latency.
| Metric | Edge Processing | Origin Processing | Improvement |
|---|---|---|---|
| Latency (p50) | 8–15 ms | 120–300 ms | 15–20x faster |
| Cache Hit Ratio | 85–95% | N/A | Reduces origin load |
| TLS Handshake | 1–5 ms (nearby PoP) | 50–150 ms | 10–30x faster |
| Bandwidth Cost | $0.01–0.04/GB | $0.05–0.12/GB | 3–5x cheaper |
| Availability | 99.99% (multi-PoP) | 99.9% (single DC) | 10x fewer outages |
Rule Types
Managed Rulesets
Pre-built rule sets maintained by the CDN provider or security vendors:
- OWASP Core Rule Set (CRS) — Protects against SQL injection, XSS, RCE, LFI/RFI, and other OWASP Top 10 attacks
- CDN-specific rules — Provider-maintained rules updated for emerging threats
- Vulnerability-specific rules — Rapid rules for newly disclosed CVEs (Log4j, Spring4Shell, etc.)
Custom Rules
Rules you write for your specific application:
# Block requests to admin paths from outside company IP range
IF path matches "/admin/*"
AND source_ip NOT IN 203.0.113.0/24
THEN block
# Rate limit login attempts
IF path = "/api/login"
AND method = "POST"
THEN rate_limit(10 requests/minute per IP)
# Block known bad user agents
IF user_agent contains "sqlmap" OR "nikto" OR "nessus"
THEN blockRate-Based Rules
Trigger when request volume from a single source exceeds a threshold. More flexible than static rate limiting because they can combine rate with request attributes.
WAF Modes
| Mode | Behavior | Use When |
|---|---|---|
| Detection (log only) | Log matches but don't block | Initial deployment, tuning rules |
| Prevention (block) | Block matching requests | Production after tuning |
| Challenge | Serve CAPTCHA or JS challenge | Suspicious but not definitively malicious |
Best practice: deploy new rules in detection mode first. Review logs for false positives. Move to prevention after confirming rules match only actual attacks.
False Positives
The biggest WAF challenge is false positives — blocking legitimate requests. Common causes:
- SQL-like syntax in legitimate content (e.g., code snippets, educational content)
- Overly broad regex patterns matching normal text
- API payloads containing encoded data that triggers rules
Mitigation: Create allowlist rules for known-good patterns, tune sensitivity per URL path, use anomaly scoring instead of hard blocks.
CDN WAF Comparison
- Cloudflare WAF — Managed rules + OWASP CRS + custom rules. Included in Pro+ plans.
- AWS WAF — Customizable rules integrated with CloudFront. Pay per rule and request.
- Akamai Kona Site Defender — Enterprise WAF with adaptive security intelligence.
- Fastly WAF — Signal Sciences-based WAF with SmartParse (context-aware detection).
WAF and Performance
CDN WAFs are designed for minimal latency impact. Processing happens in the same edge server that handles caching and TLS — no separate appliance or network hop. The WAF evaluates requests in parallel with other edge processing. Monitor WAF latency via performance metrics.