Three deployment models: on-prem appliance (Imperva, F5), virtual/host (ModSecurity, NAXSI) and cloud/CDN (Cloudflare, AWS WAF, Akamai). Each has its own tradeoffs in latency, cost and control.
What WAF is
A WAF (Web Application Firewall) is a specialized firewall that inspects HTTP/HTTPS traffic and blocks malicious requests against a web application or API. Unlike traditional firewalls (which operate at network and transport layers), a WAF understands the application layer protocol: it analyzes headers, body, cookies, URL parameters and JSON payloads to detect injection patterns, business-logic abuse, aggressive scraping and OWASP Top 10 style attacks.
Why it matters
For many organizations, the perimeter is no longer the corporate network — it's the set of public websites, APIs and portals exposed to the Internet. A classic firewall cannot see inside an HTTPS request, and an EDR protects endpoints, not cloud-served apps behind a CDN. WAF covers that middle layer: it filters requests attempting SQL injection, cross-site scripting, path traversal, insecure deserialization or API endpoint abuse. It's effectively mandatory for any application handling payments (PCI DSS), personal data (GDPR) or services under NIS2/DORA. Properly tuned, it prevents known vulnerabilities from being exploited before the development team patches them.
Key points
The most useful WAFs combine static rules (OWASP CRS, known signatures) with behavior-based detection and IP reputation. Without that second layer, an attacker with a novel payload slips past basic filters.
A poorly tuned WAF blocks legitimate traffic and generates more operational cost than it saves. Tune allowlists, rate limiting thresholds and endpoint-specific exclusions in a pilot phase before switching to "blocking" mode.
WAF + SIEM + threat intelligence gives full visibility. The WAF detects and blocks at the edge; the SIEM correlates with the rest of the logs; threat intelligence tells you whether the attacking IP belongs to an active campaign.
Example: blocking SQL injection on a payments API
A payments API published on a CDN with an active WAF receives POST requests to /v1/charge. An attacker tries a SQL injection in the customer_id parameter with a payload like "1' OR 1=1--". The WAF analyzes the request body, identifies the injection pattern via OWASP CRS rule 942 and returns 403 before the request reaches the backend. It raises an event to the SOC with source IP, geolocation, user-agent and rule signature, and adds the IP to the automatic blocklist for 24h. The application never sees the malicious request, doesn't waste resources defending and doesn't expose the backend.
Common mistakes
- Activating the WAF in 'block' mode directly against production traffic. The correct approach is to run in 'detect/monitor' first, measure false positives and only then switch to blocking on selected rules.
- Assuming a WAF replaces secure code. A WAF mitigates, but the bug is still in the code. Both layers (WAF + secure coding + SAST/DAST review) are complementary.
- Not protecting internal APIs behind the perimeter WAF. If an attacker gets initial execution inside the cloud environment, internal APIs are often left unfiltered.
- Confusing WAF with CDN. A CDN distributes content and reduces latency, but it's only a WAF if a specific WAF module is active. Some services bundle both, but you have to enable and maintain them explicitly.
Related terms
Related services
This concept may relate to services such as:
Frequently asked questions
Is a WAF the same as a traditional firewall?
No. A network firewall filters by IP, port and protocol (layers 3-4). A WAF understands HTTP/HTTPS and analyzes the content of requests (layer 7): parameters, cookies, JSON body, headers. They complement each other, they don't replace each other.
How does WAF relate to OWASP Top 10?
Most WAFs are calibrated against the OWASP Top 10 (injections, XSS, deserialization, broken authentication, etc.) using the OWASP Core Rule Set as a baseline. They don't cover 100% of vulnerabilities, but they block the most actively exploited vectors.
Is a WAF enough to meet PCI DSS?
A properly configured WAF meets PCI DSS v4.0.1 requirement 6.4.2 for public-facing web applications, but does not replace the rest of the controls (vulnerability management, CDE segmentation, monitoring, etc.). It's a necessary component, not the only one.