iFastHostingWhat a web application firewall does
A filter sitting in front of your site that inspects requests and blocks patterns that look like an attack, before they reach your code.
A web application firewall, almost always shortened to WAF, sits between visitors and your website and inspects every request before deciding whether to let it through. It looks specifically at the content and structure of web traffic — the kind of thing a normal firewall does not examine at all — and blocks requests that match patterns associated with common attacks, without your application ever seeing them.
How it differs from an ordinary firewall
A traditional network firewall controls which ports and addresses can connect to a server at all — a fairly coarse decision made before any web request is even parsed. A web application firewall works one level up: it assumes the connection itself is allowed, then reads the actual content of each web request — the address requested, the parameters submitted, the data in a form post — looking for patterns that resemble known attack techniques rather than simply deciding whether a connection is permitted in the first place.
| Network firewall | Web application firewall | |
|---|---|---|
| Operates on | Connections, ports, addresses | The content of web requests themselves |
| Typical decision | Is this address allowed to connect at all? | Does this specific request look like an attack pattern? |
| Blind to | What is actually inside an allowed request | Anything below the web layer, such as raw network-level attacks |
What it actually catches
A WAF is built to recognise the shape of known attack techniques rather than understand your specific application. Common categories include:
- SQL injection attempts — a request trying to insert database commands into a field meant for ordinary input, such as a search box or a login form.
- Cross-site scripting attempts — a request trying to insert a script into a page that will later be shown to other visitors.
- Known vulnerability signatures — requests specifically shaped to exploit a published vulnerability in common software, sent broadly across many sites at once regardless of whether that particular software is actually running there.
- Excessive or automated request patterns — a volume or pattern of requests from a single source consistent with automated scanning or brute-force attempts, distinct from ordinary browsing behaviour.
None of this requires the WAF to understand what your specific site does — it is working from the general shape of a request, matched against patterns known to be associated with attacks regardless of the target.
Where a WAF sits, and what that means for you
A WAF can run as a service in front of your site, inspecting traffic before it ever reaches your server, or as a module running on the server alongside your application. Either way, the core value is the same: a request identified as malicious never reaches your application code at all, which means even a vulnerability you do not yet know about in your own site can, in many cases, still be blocked if the request attempting to exploit it matches a known attack pattern.
A WAF blocking a known attack pattern buys time and reduces exposure, but it does not patch the actual vulnerability in your code, plugin or theme. Keeping software updated remains necessary even with a WAF in place — think of it as reducing risk while the real fix is applied, not a substitute for applying it.
What it cannot do
A WAF works from patterns, so it is naturally strongest against known, well-understood attack techniques and weaker against something genuinely novel that does not resemble anything it has been configured to recognise. It also cannot protect against a compromise that does not travel through a web request at all — a leaked password used to log in directly and legitimately, for instance, looks identical to a real login to a WAF inspecting request patterns, because nothing about the request itself is unusual. It is one layer in a broader security setup, not a single answer that removes the need for the others: strong passwords, two-factor authentication, correct file permissions, and keeping software updated all cover ground a WAF does not reach.
Rule-based versus adaptive filtering
Some WAFs work from a fixed, published set of rules describing known attack patterns, updated periodically as new techniques become widely understood. Others adapt their filtering based on the traffic a specific site actually receives over time, building up a picture of what normal requests to that site look like and treating significant deviations from that pattern with more suspicion. Neither approach is strictly better in every case — a fixed rule set is predictable and easy to reason about, while an adaptive one can catch something unusual to a specific site that a generic rule would miss, at the cost of occasionally flagging legitimate but unusual traffic as suspicious.
Does every site need one?
A WAF is most valuable for sites handling sensitive data, running custom code with a larger attack surface, or having previously been targeted specifically. For a straightforward site built on well-maintained, regularly updated software, the layers covered elsewhere in this section — strong unique passwords, two-factor authentication, correct file permissions, and prompt updates — address the large majority of realistic risk on their own. A WAF adds a further layer on top of that foundation rather than substituting for it, and is worth considering once the basics are already solidly in place.
Related reading
Automated tools quietly try thousands of guesses against your login form. A few layered defences make that approach stop being worthwhile.
How to block an IP address from your siteTwo reliable ways to stop a specific address reaching your site, and why blocking one IP rarely stops a determined, repeated attacker for long.
What a DDoS attack is, and what you can doA flood of traffic from many sources at once, aimed at overwhelming a site rather than breaking into it. Here is what it actually looks like.
How to add security headers to your siteA handful of response headers close off entire categories of attack for very little effort. Here is what each does and how to add them.