- How a WAF differs from a firewall
- The kinds of attack it relates to
- What a WAF does not cover
- Four decisions before you deploy
The short answer
A WAF — a web application firewall — looks at the content of requests arriving at your website or application and refuses to pass the problematic ones. A traditional firewall decides which doors are open. A WAF stands at a door you have deliberately left open and looks at what is trying to come through. Different layers, so one does not replace the other.
The difference, using a building
Think of your office. A traditional firewall decides the entrances: the front door is open, the back door and the fire exit are shut. It decides by where traffic comes from and which door it uses, not by what it is carrying.
A WAF stands at the front door you have left open and looks at what people are carrying. Anything obviously wrong does not come in. Closing the door would stop the business, so the judgement has to be made on contents instead.
| Traditional firewall | WAF | |
|---|---|---|
| What it examines | Source, destination, port | The content of HTTP/HTTPS requests |
| Typical decision | Allow traffic on this port only | Refuse input in this shape |
| What it protects | The network as a whole | The web application |
| Blind spot | What happens beyond an open port | A valid-looking login with stolen credentials |
If you run a public website, ports 80 and 443 stay open. A traditional firewall has nothing to say about what travels through them. That gap is the WAF's job.
The attacks it relates to
The well-known categories of attack against web applications include SQL injection, which targets the database through crafted input, and cross-site scripting, which gets unintended script to run in a visitor's browser. AWS documents that AWS WAF conditions can include the presence of SQL code that is likely to be malicious and the presence of a script that is likely to be malicious.
The mechanics are not covered here. What matters from the defender's side is that most of these trace back to how input values are handled, and that the requests carrying them tend to share recognisable shapes. That is precisely why inspecting at the door works at all.
The real fix is in the application code and in keeping your software updated. Treat a WAF as the layer that holds things while you get there, and covers the parts you cannot fix yourself.
What it covers and what it does not
The vendors' own documentation gives you the shape of it. Cloudflare describes its WAF as checking incoming web and API requests and filtering unwanted traffic based on sets of rules called rulesets, and lists three rule types: managed rules, custom rules and rate limiting rules. AWS describes AWS WAF as monitoring the HTTP and HTTPS requests forwarded to protected resources, with actions including allow, block, count, and CAPTCHA or silent challenge checks.
Outside the scope, you will find:
- A login with the correct username and password. It is indistinguishable from the real user.
- Misconfigured permissions. A page that should be restricted but opens for anyone is being requested perfectly normally.
- Information exposed by a server or cloud misconfiguration.
- Anything that does not pass through the WAF at all: a management port, or an old site parked on another domain.
"We have a WAF, so we are covered" does not hold. A WAF sees the traffic that goes through it. Unpatched software, and accounts left active for people who left the company, are exactly as they were.
Decide these before you deploy
- Where it sits. Some run in front of your server, at the CDN; others run on the server itself. The first is usually simpler to set up, the second easier to tune to your own environment.
- Who fixes false positives. A contact form whose message body contains a lot of punctuation will get blocked at some point. Decide now who receives that complaint and who adjusts the rule.
- Whether to start without blocking. Most services can log matches without acting on them. Run that way first and you can see what would have been caught.
- Cost and plan. Features differ by tier. Confirm in the provider's own documentation that the capability you are buying it for is included in the plan you are signing.
How this looks in practice
Take a hypothetical example: a manufacturer with fifteen staff runs a site with a contact form and a simple members' area, on shared hosting, with nobody in-house dedicated to it.
At that size, choose the type that runs in front of the server and leave it in log-only mode for two weeks. Review what is being matched, confirm no genuine enquiries are in there, then switch to blocking. Alongside that, they added multi-factor authentication to the login, so the WAF is not carrying the whole weight. They also changed the admin URL to something less guessable, but only as an extra: an unknown URL is no substitute for access control.
In summary
A WAF inspects what arrives at the doors you have chosen to leave open. That is a different role from a network firewall, not a substitute for one. Judge its capabilities by what the vendor documents, decide who handles false positives, and start in log-only mode. Handled that way, it becomes easier to manage without a specialist on staff.