Web Application Firewalls

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.

What a WAF does

Rule-based filtering

Pattern-match against known attack signatures:

- SQL injection: `' OR 1=1 --`

- XSS: `<script>...`

- Path traversal: `../../etc/passwd`

- Command injection: `; cat /etc/passwd`

Block requests matching the patterns.

OWASP Core Rule Set (CRS)

A standard ruleset for WAFs. Covers most well-known web attacks. Foundation that most WAFs build on.

Rate limiting

Limit requests per client. Mitigates brute force, scraping, basic DoS.

Bot detection

Distinguish humans from bots. Block scrapers, scanners, credential stuffers.

IP reputation

Block requests from known-bad IPs (TOR exits, recently-abusive ranges).

Custom rules

Organization-specific rules: "block requests with this header"; "rate-limit /login by IP."

Major WAFs

AWS WAF

Native to AWS. Integrates with CloudFront, ALB, API Gateway. Rule-based; managed rules available; pay per request.

For AWS-hosted apps, the default choice.

Cloudflare

CDN with integrated WAF. Strong on DDoS protection; large managed rule library.

For sites in Cloudflare CDN, often the right answer.

Imperva

Enterprise-focused. Comprehensive; expensive; common in regulated industries.

Akamai

Enterprise CDN with WAF. Similar position to Imperva.

F5

Hardware/cloud WAF. Enterprise.

ModSecurity

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.

When WAF helps

Defense in depth

Even with secure code, WAF catches:

- 0-day attacks (vulnerability disclosed but not yet patched in your code)

- Bots scanning for known vulnerabilities

- Mass attacks against widely-used libraries

The WAF buys time during patching.

DDoS mitigation

CDN-integrated WAFs absorb large attacks before they hit your infrastructure. AWS Shield Advanced, Cloudflare DDoS protection.

Compliance

Some frameworks (PCI-DSS) require a WAF or equivalent.

Bot mitigation

Credential stuffing, scraping, scalping. WAFs detect and block.

When WAF is theater

Security via WAF only

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.

Tuning ignored

WAF deployed; default rules applied; never tuned. False positives accumulate; real attacks slip through (because rules are too generic or too disabled).

Performance ignored

WAF inspection adds latency. At scale, the cost is real. Not a reason to skip WAF, but plan for it.

False positives

The hardest part of WAF operation. Default rules block too much:

- Legitimate user inputs that look like attacks

- API requests that resemble injection attempts

- Specific application patterns

Tuning:

- Whitelist legitimate patterns

- Adjust rule sensitivity

- Mode: detect-only initially; block once tuned

A noisy WAF gets bypassed by frustrated developers. A WAF in detect-only mode forever provides no protection.

Specific patterns

Detect, then block

Run new rules in detect-only first. Watch for false positives. Switch to block when confident.

Per-route configuration

Different routes have different threat profiles. `/api/upload` accepts file uploads; `/login` is rate-limit-sensitive. Tune per route.

Geographic blocking

If your service is US-only, blocking traffic from other countries reduces attack surface. Not a primary defense; complementary.

Custom rules for known threats

Recently exploited vulnerability in your stack? Custom WAF rule blocks it while you patch.

Logging and analytics

WAF logs are useful: what's being blocked? What attacks are common? Feed to SIEM.

The OWASP Top 10

WAFs primarily defend against the OWASP Top 10:

1. Broken Access Control

2. Cryptographic Failures

3. Injection (SQL, command, etc.)

4. Insecure Design

5. Security Misconfiguration

6. Vulnerable Components

7. Identification and Authentication Failures

8. Software and Data Integrity Failures

9. Security Logging and Monitoring Failures

10. Server-Side Request Forgery

Note: WAF helps most with #3 (injection), partially with #6 (vulnerable components — virtual patching). Other categories require different controls.

Common failure patterns

- **WAF as the only defense.** Secure code matters more.

- **Default rules without tuning.** Blocks legitimate; misses real.

- **WAF behind nothing.** No CDN; WAF capacity hit by DDoS.

- **No log analysis.** WAF blocking; no learning from it.

- **Bypassed by attackers.** WAF circumvented; attack continues.

- **Compliance theater.** Box checked; not actually protecting.

A reasonable approach

For typical web apps:

1. CDN with integrated WAF (Cloudflare, AWS WAF + CloudFront)

2. Default managed rules (OWASP CRS)

3. Initial detect-only mode; tune for false positives

4. Switch to block mode once tuned

5. Custom rules for app-specific threats

6. Logs to SIEM or analytics

7. Treat WAF as one layer; not the only one

Further Reading

- [NetworkSecurityFundamentals](NetworkSecurityFundamentals) — Broader network security

- [CdnArchitecture](CdnArchitecture) — Edge layer

- [CloudSecurityFundamentals](CloudSecurityFundamentals) — Cloud-specific

- [VulnerabilityManagement](VulnerabilityManagement) — Adjacent practice