What is a WAF, and does your site really need one?
A web application firewall sounds like enterprise overkill until the day it quietly blocks the attack that would have ruined your week. What a WAF does, what it cannot do, and who actually needs one.
A WAF, or web application firewall, inspects the content of incoming HTTP requests and blocks the ones matching known attack patterns — SQL injection, cross-site scripting, path traversal — before they reach your application. Run at the edge, it stops malicious traffic before it costs you anything. It is not a substitute for writing secure code; it is a layer in front of it.
Most people meet a WAF the way they meet their home insurance: after something has already gone wrong, and usually wishing they had set it up sooner. It is not a glamorous feature. It is the bouncer at the door, checking every request and turning away the ones carrying something sharp.
What separates a WAF from an ordinary firewall
A network firewall thinks in ports and IP addresses: allow 443, block that subnet, done. It has no idea what is inside the traffic it permits, and it cannot — everything arriving on port 443 looks identical from where it stands.
A web application firewall works one layer up, at HTTP. It reads the URL, the query string, the headers, the cookies and the request body, and looks for the patterns attackers use. To a network firewall, GET /products?id=5 and GET /products?id=5' OR '1'='1 are the same request to the same port. To a WAF they are very obviously not.
What a WAF does with a request
Three possible verdicts, and the third is the one that makes a WAF usable rather than infuriating.
Allow
Nothing matched. The request continues to your application as normal, with no measurable delay.
Block
Matched a known attack pattern, or came from a banned address. Rejected with a 403 before your application is ever involved.
Challenge
Suspicious but not conclusively bad. The client is asked to prove it is a real browser — a proof-of-work puzzle or similar — and continues if it passes. This is how you handle traffic you are not sure about without blocking real customers.
Rule order decides everything
A WAF evaluates rules by priority, and the first match wins. That is powerful and very easy to get backwards. An allow rule sitting above your block rules will happily wave through the exact traffic you wrote the block rules to stop, and the WAF will report itself as working perfectly the whole time.
If your WAF "is not blocking", check rule order before anything else. A broad allow rule above your block rules is far and away the most common reason an attack passes through a firewall that is technically switched on.
The part nobody mentions: false positives
A WAF that has never blocked a legitimate request is a WAF with its rules turned down too far. The tension is inherent — you are pattern-matching on text, and real text sometimes looks like an attack.
The classic examples are worth knowing in advance because they will happen to you. A CMS where an editor writes an article about SQL injection, and saving it trips the SQL injection rule. A form where someone's surname contains an apostrophe. A developer pasting a stack trace into a support ticket. A marketing URL with an unusual encoded parameter.
Which is why every WAF deployment should start the same way: run it in monitoring mode first. Log what it would have blocked, leave it for a week or two of real traffic, then read the log. You will find two or three rules that need an exception for your specific application, and you will find them without having spent that fortnight rejecting customers.
Edge WAF or origin WAF
| At your origin | At the edge | |
|---|---|---|
| Where attacks stop | After reaching your server | Before reaching your server |
| Load from bad traffic | You pay for all of it | Never arrives |
| Behaviour during a flood | Can be overwhelmed | Absorbed across the network |
| Sees decrypted request body | Yes | Yes — TLS terminates at the edge |
| Applies to all your sites at once | Per server | Per zone, centrally |
An origin WAF has already lost bandwidth and CPU by the time it decides to reject something. During a serious automated attack that is the difference between a filtered log line and a server that stops responding.
What a WAF will not do for you
Worth being blunt, because WAFs get sold as a security strategy and they are not one.
- It does not fix vulnerable code. It makes exploitation harder, buying you time to patch. The vulnerability is still there.
- It does not stop logic flaws. If your checkout accepts a negative quantity, every request doing so is perfectly well-formed HTTP.
- It does not stop credential stuffing on its own. A login attempt with a real stolen password looks exactly like a legitimate login. That is rate limiting and MFA territory.
- It does not replace patching. A virtual patch at the edge is a useful stopgap for the days between disclosure and your deploy — not a permanent answer.
So do you need one?
If your site is a static brochure with no forms, no logins and nothing to steal, you can reasonably wait. The moment you accept user input, run a login, take payments, or store anything you would hate to leak, a WAF stops being optional. The attacks it blocks are automated and constant — scanners are probing your site right now for the WordPress vulnerabilities of 2023, whether or not you run WordPress.
Frequently asked questions
What is a WAF?
A WAF, or web application firewall, is a security layer that inspects the content of incoming HTTP requests — URLs, headers, cookies and body data — and blocks those matching known attack patterns such as SQL injection, cross-site scripting and path traversal. Unlike a network firewall, which only sees ports and IP addresses, a WAF understands the application layer.
What is the difference between a WAF and a firewall?
A network firewall filters traffic by port, protocol and IP address, and cannot see what is inside the requests it allows through. A web application firewall operates at the HTTP layer and inspects the actual content of each request. A network firewall sees two requests to port 443 as identical even when one contains an SQL injection payload; a WAF does not.
Does a WAF slow down my website?
Barely. Rule evaluation on a modern edge WAF typically adds under a millisecond per request, which is not perceptible next to network latency. A WAF running at the CDN edge usually improves overall performance in practice, because malicious and automated traffic is rejected before it consumes any origin capacity.
Can a WAF block legitimate visitors?
Yes, and it will if deployed carelessly. False positives typically involve content that resembles attack syntax — an article about SQL injection, a surname containing an apostrophe, a pasted stack trace. The standard mitigation is to run the WAF in monitoring mode for a week or two first, review what it would have blocked, and add exceptions before enforcing.
Do I still need secure code if I have a WAF?
Absolutely. A WAF is a filter in front of your application, not a fix for what is inside it. It makes known vulnerability classes harder to exploit and buys time between a disclosure and your patch, but the underlying flaw remains exploitable by any request the rules do not match. Treat it as defence in depth, never as a substitute.
Does a small website need a WAF?
If it accepts any user input — a login, a contact form, a search box, a comment field — then yes. Attacks against small sites are almost entirely automated and untargeted: scanners sweep the whole internet probing for known vulnerabilities and do not care how much traffic you get. A purely static site with no forms and no admin panel is the one case where it can reasonably wait.
A WAF reads incoming requests and blocks the malicious ones before they reach your application. Put it at the edge so bad traffic never costs you, start in monitoring mode so you find your false positives safely, mind your rule order so allow rules do not undermine block rules — and keep patching, because a WAF buys time rather than immunity.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
