A Web Application Firewall (WAF) sits at the edge of your application; inspects HTTP traffic; blocks malicious requests. Common defenses: SQL injection, XSS, OWASP Top 10 patterns, bot traffic, DDoS.
WAFs are useful but often oversold. They're one layer of defense, not a replacement for secure code.
Pattern-match against known attack signatures:
' OR 1=1 --<script>...../../etc/passwd; cat /etc/passwdBlock requests matching the patterns.
A standard ruleset for WAFs. Covers most well-known web attacks. Foundation that most WAFs build on.
Limit requests per client. Mitigates brute force, scraping, basic DoS.
Distinguish humans from bots. Block scrapers, scanners, credential stuffers.
Block requests from known-bad IPs (TOR exits, recently-abusive ranges).
Organization-specific rules: "block requests with this header"; "rate-limit /login by IP."
Native to AWS. Integrates with CloudFront, ALB, API Gateway. Rule-based; managed rules available; pay per request.
For AWS-hosted apps, the default choice.
CDN with integrated WAF. Strong on DDoS protection; large managed rule library.
For sites in Cloudflare CDN, often the right answer.
Enterprise-focused. Comprehensive; expensive; common in regulated industries.
Enterprise CDN with WAF. Similar position to Imperva.
Hardware/cloud WAF. Enterprise.
Open-source WAF library. Used in many products including the AWS Marketplace WAF rules.
For most cloud apps, AWS WAF or Cloudflare. For self-hosted, ModSecurity behind Nginx.
Even with secure code, WAF catches:
The WAF buys time during patching.
CDN-integrated WAFs absorb large attacks before they hit your infrastructure. AWS Shield Advanced, Cloudflare DDoS protection.
Some frameworks (PCI-DSS) require a WAF or equivalent.
Credential stuffing, scraping, scalping. WAFs detect and block.
WAF as a substitute for secure coding. Eventually fails; the original vulnerability is still in the code.
WAF is one layer. Secure code, dependency management, vulnerability management — these matter more.
WAF deployed; default rules applied; never tuned. False positives accumulate; real attacks slip through (because rules are too generic or too disabled).
WAF inspection adds latency. At scale, the cost is real. Not a reason to skip WAF, but plan for it.
The hardest part of WAF operation. Default rules block too much:
Tuning:
A noisy WAF gets bypassed by frustrated developers. A WAF in detect-only mode forever provides no protection.
Run new rules in detect-only first. Watch for false positives. Switch to block when confident.
Different routes have different threat profiles. /api/upload accepts file uploads; /login is rate-limit-sensitive. Tune per route.
If your service is US-only, blocking traffic from other countries reduces attack surface. Not a primary defense; complementary.
Recently exploited vulnerability in your stack? Custom WAF rule blocks it while you patch.
WAF logs are useful: what's being blocked? What attacks are common? Feed to SIEM.
WAFs primarily defend against the OWASP Top 10:
Note: WAF helps most with #3 (injection), partially with #6 (vulnerable components — virtual patching). Other categories require different controls.
For typical web apps: