What is a WAF (Web Application Firewall)?

How a WAF works

A WAF is a reverse proxy: traffic is addressed to it rather than directly to your server, it decides what to do with each request, and forwards only what passes. Because it terminates the connection itself, it sees the fully assembled request — including headers a network device would never parse.

For each request the WAF evaluates a set of rules. Some are signature-based: a pattern like `' OR 1=1--` in a query parameter is a well-known SQL injection probe. Others are behavioural: this client has requested four hundred distinct URLs in a minute, or is sending a browser user-agent with none of the headers a browser actually sends. The outcome is an action — allow, challenge, rate limit, log, or block.

Modern WAFs score rather than switch. Instead of a single rule deciding the verdict, many weak signals combine into a risk score, and the action depends on where that score lands. This matters because any individual signal has false positives; a combination of six of them rarely does.

What a WAF blocks

The baseline for most WAFs is the OWASP Top 10 — the industry's consensus list of the most critical web application risks. A managed ruleset covers these 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 — requests to known-vulnerable endpoints and interpreters
• Sensitive file exposure — requests for .env, .git, backups and config files
• Request smuggling — malformed Content-Length and Transfer-Encoding combinations
• Credential stuffing — high-volume login attempts using leaked username/password pairs

WAF vs. network firewall vs. DDoS protection

These three are often confused because all of them sit in front of a server and drop traffic. They operate at different layers and solve different problems.

The 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 is usually more expensive than letting a probe through to an application that was patched anyway.

This is why serious WAFs default to challenging rather than blocking for anything ambiguous. A challenge that a browser solves in the background costs a real visitor a fraction of a second and costs an automated tool the entire attack, because it cannot solve it at all.

It is also why corroboration matters. A single client with an odd header combination is far more likely to be a privacy extension or a corporate proxy than an attacker. The same odd combination arriving from hundreds of unrelated addresses at once is a botnet reusing one template — and only then is it safe to act on.

How a WAF is deployed

There are three common models. A cloud WAF sits in front of your origin at DNS level: you point your nameservers at the provider and traffic is inspected at their edge. A host-based WAF runs as a module inside your own web server. An appliance-based WAF is hardware in your own datacentre.

Cloud WAFs dominate for public websites because attacks are absorbed before they consume your bandwidth, and because the ruleset is maintained for you. The trade-off is that traffic passes through a third party, which makes their TLS handling and data-processing practices part of your security posture.