What is a web application firewall?

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.

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.