What is a WAF (Web Application Firewall)?

02What a WAF blocks

Most WAFs start from a managed ruleset that covers generic attack classes without you writing anything:

• SQL injection — manipulating database queries through user input
• Cross-site scripting (XSS) — injecting scripts that run in another visitor's browser
• Path traversal — using ../ sequences to read files outside the web root
• Remote code execution probes — exploit strings aimed at known-vulnerable frameworks
• Sensitive file exposure — requests for .env, .git, backups and configuration files
• Request smuggling — conflicting Content-Length and Transfer-Encoding headers, which RFC 9112 says ought to be handled as an error
• Credential stuffing — high-volume login attempts using leaked username and password pairs

03What a WAF can and cannot cover in the OWASP Top 10

The OWASP Top 10, now in its 2025 edition, is often quoted as a WAF's job description, but only part of it is visible in a request. A WAF is strong against injection and helps with path traversal, exposed files and credential stuffing, while insecure design and most access-control flaws live in application logic that no request filter can see.

04Virtual patching: buying time after a disclosure

For a well-maintained application, a WAF's most valuable job is covering the gap between a vulnerability becoming public and your fix reaching production. It works best when an exploit needs one distinctive request feature: a rule that strips the internal header behind the Next.js middleware bypass from outside traffic neutralises it while the upgrade goes through testing. It works less well when the payload can be rephrased: early Log4Shell rules matched the plain exploit string, and within days attackers rebuilt it with Log4j's own lookup syntax to slip past them. Virtual patching covers when a rule holds and the bug classes it cannot reach.

05WAF vs. network firewall vs. DDoS protection

All three sit in front of a server and drop traffic, but at different layers and for different problems. Whether a firewall alone can hold off a flood is answered in can a firewall stop a DDoS attack.

06The real cost: false positives

The hard part of running a WAF is not catching attacks — it is not catching customers. A rule tuned aggressively enough to catch every exploit will eventually block a legitimate request that happens to contain a suspicious string, and blocking a paying customer usually costs more than letting a probe reach an application that was patched anyway.

CRS makes the trade-off explicit with paranoia levels. Level 1 is designed to cause few, ideally zero, false positives; level 2 suits sites handling real user data and expects some tuning; levels 3 and 4 accept many false positives in exchange for catching more. Every WAF has the same dial, labelled or not.

Two habits keep the cost down. Challenge rather than block when a request is ambiguous: a background check costs a real visitor a moment and forces simple automation to run a full browser, although headless browsers can pass it too, so it raises cost rather than proving anything. And run new rules in log-only mode first, then write exclusions for the legitimate cases; CRS recommends exclusions over editing rules, so updates do not overwrite your changes.

07How a WAF is deployed

There are three common models. A cloud WAF sits in front of your origin at DNS level, so traffic is inspected at the provider's edge. A host-based WAF runs as a module inside your own web server. An appliance is hardware or a virtual machine in your own network.

Cloud WAFs are the common choice for public websites because attacks are absorbed before they consume your bandwidth and the ruleset is maintained for you; the trade-off is that a third party's TLS handling becomes part of your security posture. For WordPress, the plugin versus cloud WAF comparison works through the same choice.

08Checking a WAF after go-live

A WAF only protects traffic that passes through it, so the first checks after switching are about the path rather than the rules.

• Confirm the hostname resolves to the provider's edge and the response headers come from the proxy; the HTTP headers checker shows both from outside your network
• Send a harmless probe, like the first command below, and confirm it is blocked or challenged rather than answered by your application
• Make sure the origin answers only the provider, or every rule can be bypassed; hiding your origin IP covers the firewall side
• Restore real visitor addresses in your logs from the header the provider documents, trusting it only from the provider's ranges; nginx real IP shows the module settings and how to prove they work

# a harmless SQL-injection-shaped probe: expect a block or challenge, not your page
curl -s -o /dev/null -w '%{http_code}\n' "https://www.example.com/?id=1%27%20OR%20%271%27=%271"

# nginx at the origin, http level: did this connection come from the provider?
geo $realip_remote_addr $via_proxy {
    default         0;
    203.0.113.0/24  1;
}

# inside the site's server block: restore the visitor address, refuse direct hits
set_real_ip_from 203.0.113.0/24;
real_ip_header   X-Forwarded-For;
if ($via_proxy = 0) { return 444; }