What is a Web Application Firewall (WAF), and how is it different from a network firewall or NGFW?
A WAF is an Application-Layer Firewall specifically protecting web servers — it parses HTTP/HTTPS requests and blocks attacks like SQL injection, XSS, and CSRF. It works alongside the network firewall, not as a replacement, and operates at OSI Layer 7.
WAF vs other firewalls:
| Tier | Protects | Inspects |
|---|---|---|
| Packet Filter | Network | IPs, ports |
| Stateful FW | Network | Connection state |
| NGFW | Network + apps | Packets, app identity, threats |
| WAF | Web servers specifically | HTTP request structure, body, headers, cookies |
What a WAF blocks:
The OWASP Top 10 — including:
- SQL Injection (
' OR 1=1 --) - Cross-Site Scripting (
<script>alert(1)</script>) - CSRF (cross-site request forgery)
- Local/Remote File Inclusion
- Authentication / session attacks
Deployment forms:
| Form | Where it sits |
|---|---|
| Bridge | Transparent L2 device — invisible to clients |
| Router | L3 device — has its own IP |
| Reverse Proxy | Most common — clients connect to WAF, WAF proxies to web servers |
| On the server (mod_security on Apache) | Software module on the web server itself |
Two security models:
| Model | Approach | Trade-off |
|---|---|---|
| Negative (blacklist) | Block known attack patterns | Easy setup, but new attack patterns slip through |
| Positive (whitelist) | Allow only known-good request patterns | Strict but high config burden — every form field/URL must be defined |
The "pro-active" benefit:
"Pro-aktive Schutz gegen neue (ev. noch nicht entdeckte) Sicherheitslücken möglich"
Even if the web app has a zero-day vulnerability, a properly configured WAF can block exploits generically — e.g., a WAF rule blocking '; DROP TABLE blocks any new SQL injection attempt regardless of which endpoint is being attacked.
The disadvantages:
| Disadvantage | Detail |
|---|---|
| Configuration burden | Whitelisting every form field/parameter is enormous work |
| Each app release may break the WAF config | New endpoints, changed validation → WAF policy must be updated |
| Knowledge transfer required | Developer knowledge → firewall admin knowledge |
| False negatives | Real attacks slip through because patterns aren't recognized |
| False positives | Legitimate traffic blocked → user complaints |
The WAF tuning challenge:
A new WAF deployment in "blocking" mode often breaks the application immediately. The standard procedure:
- Deploy in monitor-only mode for 2-4 weeks.
- Review logs, identify false positives.
- Whitelist legitimate patterns.
- Switch to blocking only after the false-positive rate is low.
Tip: Major WAF products: Airlock (Swiss), Imperva, F5 ASM, Cloudflare WAF, AWS WAF, mod_security (open-source). As of the 2026 source window, cloud-integrated WAFs (Cloudflare, AWS) are very widely deployed because they're bundled with the provider's CDN/cloud — the WAF is "built in" rather than a separate purchase.
Go deeper:
Web application firewall — Wikipedia — covers the positive vs negative security models and deployment forms (reverse proxy, bridge, on-server module).- OWASP Top Ten — the canonical list of web-app risks (SQLi, XSS, …) that every WAF ruleset is built to mitigate.