What is a web application firewall (WAF)?

Three steps, and the whole category is the same shape.

A request arrives and is assembled into something readable: a method, a path, headers, a body. Rules are applied to that, describing shapes of request that should not be served: values that look like attempts to inject something, patterns of behaviour unlike ordinary use, requests aimed at paths that should never be reached from outside.

A decision follows. The request is passed on, refused, or in some arrangements recorded without action, which is the mode used to see what enforcement would do before it does it, described under operations.

Everything else in the category is variation on those three steps: where the layer runs, who writes the rules, and how much is observed before anything is refused.

Because a large class of attacks arrives as perfectly ordinary traffic.

Requests exploiting an application do not look wrong at the network level. They use the port you deliberately opened, they are well formed, and they often come from addresses with nothing remarkable about them. What distinguishes them is what they ask for, and only something reading the request can tell.

The boundary is the other half of the answer, and it is the part sales material tends to leave out. It cannot fix an application: a missing authorisation check or an operation that can be replayed remains exactly as reachable, just harder to reach. It cannot see traffic that never becomes a request. And its mistakes are visible to your own users, since a refused legitimate request looks like a broken site rather than like a defence working. Which defence sees what is set out under WAF vs other defences, and the attacks themselves under attacks.

Why a page may say a firewall blocked the request

Some visitors meet the refusal from the other side. A message saying that the transfer has triggered a web application firewall is the second outcome described under how it works: the layer read the request, a rule matched, and the request was refused instead of passed on. The message alone does not name the rule.

For a visitor, the useful facts are what was sent and when. Sending the same input again changes nothing if a rule is the cause, while the site's operator, in a WAF that keeps a record of refusals, can find the request and tell whether it was a legitimate one. For the operator this is the false-positive case: a legitimate request refused, which users see as a broken site. Recording before refusing is how such cases are found early.

Two different tools are easy to mix up here. A WAF filters requests coming in to a site whose owner runs it. A firewall that stops a visitor from reaching other websites works on the outgoing side, on a school or office network. A message that a website is blocked by a firewall can come from either, and which one it is decides who can change the outcome: the site's operator for a WAF, the network's administrator for the other.

The attacks a WAF is built for arrive inside ordinary requests. The best known are injection, where a form field or parameter carries database or shell syntax, such as SQL injection; cross-site scripting, where it carries script meant for other users' browsers; and path traversal, where a path climbs out of the folder it should stay in. Most of these appear among the OWASP Top 10 risks.

Many WAFs also limit how fast one client may send requests and look at who is asking, which brings in floods of requests and bots such as credential stuffers and scrapers. What stays out of reach is anything decided inside the application, such as whether this user may see that record, and anything that never becomes a request.

A WAF that works from a blocklist, the negative security model, passes everything except requests that match a known bad shape. It is quick to put in place and covers the common attacks, but it only knows the attacks someone described.

One that works from an allowlist, the positive security model, refuses everything except requests that match a description of what the application expects: these paths, these parameters, values of this type and length. It catches attacks nobody has named yet, and it has to be updated every time the application changes. Most deployments mix the two, with a blocklist everywhere and an allowlist on a few sensitive endpoints.

A WAF can run as a hardware or virtual appliance in your own network, as a module inside the web server itself, or as a cloud service that requests pass through before they reach your servers. The job is the same in all three; what changes is who operates it, how it scales and where the traffic goes first.

The trade-offs between running one yourself and using a service are set out in cloud WAF vs appliance. A wider bundle that adds API and bot protection to the same layer is often called a WAAP, compared on WAF vs WAAP.

Web application firewall architecture and configuration

Web application firewall architecture starts from one question: where does the request go first? In the most direct arrangement a web application firewall works as a reverse proxy: clients talk to it, and only the requests it passes on reach the origin server. That describes an appliance and a cloud service alike. A module inside the web server reads the request in the same place, before the application code runs.

A hosted web application firewall, sometimes written WAFaaS for WAF as a service, is the cloud type. The provider runs the layer, and traffic is directed to it, for example by changing where the site's name points. Whether the engine behind any of these is commercial or open source does not change the three steps of reading, applying rules and deciding.

Web application firewall configuration comes down to three choices: where the layer sits, which rules apply to which paths, and what a match does, which is to pass, refuse or record. Starting with record, as described under where a WAF fits, lets the rules be checked against real traffic before they refuse any of it.

In a layered defence, a WAF sits between the network firewall, which decides which addresses and ports may connect, and the application, which decides what each user may do. It is the only one of the three that reads what a request asks for before the application acts on it; the difference from a network firewall is laid out on WAF vs firewall.

That position makes it a good place to refuse known attack shapes and to buy time while a flaw is fixed, which is virtual patching. It is a poor substitute for fixing the application, and it works best when it starts by recording what it would refuse, so that its mistakes can be found before your users find them.

What the uses of a firewall are

The applications of a firewall in general are filtering what may connect, separating one part of a network from another, and keeping a record of what was refused. A WAF applies the same three ideas to requests rather than to connections. It refuses known attack shapes before the application acts on them, it can keep a flawed endpoint out of reach while the flaw is fixed, and it records what it would have refused, so that its rules can be checked. None of this replaces fixing the application; it decides what reaches the application in the meantime.

An application firewall, or application layer firewall, is the same idea under a broader name: a filter that judges traffic by what it asks the application to do. The application layer is layer 7 of the OSI model, which is why the terms are used interchangeably.

The web in web application firewall narrows it to HTTP and HTTPS traffic. A product sold as an application firewall may also inspect other protocols, so the name alone does not tell you which requests it understands.

Webapp firewall, web based firewall, WAF network: same layer, different wording

Webapp firewall, web based firewall, web app firewall and the one-word spelling webapplicationfirewall all name the layer defined at the top of this page. Firewall website and website firewall describe it from the site owner's side: a filter placed in front of a website. WAF application and application WAF say the same thing with the words reversed.

WAF network needs more care. Where it means a WAF run as a cloud service, the network is the set of locations through which requests pass before they reach your servers, which is the third type in the section on types above. Where it means a firewall working on a network, with addresses and ports, it is a network firewall, a different layer. The test is the same for every variant: what does the filter read? If it reads the content of a request, it is a WAF whatever the name; if it reads addresses and ports, it is not.

How the categories of defence divide is under WAF vs other defences, what the attacks look like under attacks, and the rest of the vocabulary in this glossary.

A flood of requests is the case a WAF is least suited to alone, as described under DDoS attack, while a decoy endpoint that records what probes it is explained under honeypot.