WAF vs other defences: what each one actually sees

Each defence can only act on what it can see, and they see different amounts of the same traffic.

A network firewall works with addresses, ports, and protocols. It knows that a connection was attempted from somewhere to somewhere on some port, and it decides on that. It does not know what the request inside was asking for, because at that level there is no request yet, only a connection that might carry one.

A request-inspecting layer works with the request as a request: the method, the path, the headers, the body, and the pattern across several of them. It knows what was asked for and can refuse it on that basis. What it cannot do is act on traffic that never becomes a request, which is where its limit sits.

An intrusion-detection system sits between those, watching traffic for known signatures and behaviour across a network rather than for the meaning of one request to one application. Its strength is breadth: it sees patterns that no single request reveals. Its weakness is the same thing, since a pattern matching many things is less precise about any one of them.

The practical consequence: a defence cannot protect against what it cannot observe, and no amount of configuration changes what a category is able to see. That boundary is set out per attack type on attack layers.

Three questions, and the right instrument follows from which one you are asking.

«Something is reaching a port that should not be open.» That is addresses and ports, and it belongs to a network firewall. A request filter would never see it, because the traffic is not requests.

«Requests are arriving that my application should never have to handle.» That is the request level: injection attempts, abuse of an expensive endpoint, automated traffic hammering a form. This is what a request filter is for, and the tell is that each request is individually well formed while being something you would never want served.

«Something is happening across my network that looks like a known pattern.» That is detection across traffic rather than judgement of a single request, and it is what intrusion systems are built for. The signal here is that no individual event looks wrong while the sequence does, which is precisely what a per-request decision cannot capture.

Most sites have all three questions at different times, which is why the categories coexist rather than replace one another, and why the honest answer to «which one do I need» is usually a question back rather than a recommendation. What matters is not choosing one but knowing which one your current problem belongs to, because the wrong instrument produces confident silence instead of an answer.

Two places to know before reading anybody's comparison.

Bundling. Vendors combine categories into single offerings, so a product name says little about which capabilities are present. The useful question is never what a thing is called but what it inspects, and that question has an answer for every product regardless of how it is marketed.

This is also why comparison tables age badly. A row saying a category does or does not do something describes a market at a moment, while the underlying distinction, what each level can observe, does not move at all. Reading the distinction first makes any table easier to judge, including ours.

Deployment. The same category exists as software you run and as a service in front of you, and that difference changes operations far more than it changes capability: who patches it, what happens under load, and whether traffic terminates before your infrastructure or on it. A comparison that treats those as the same product with a different delivery method misses the part that affects your week.

Both distinctions get their own pages in this section, along with the question of how the categories divide when somebody markets them as a single thing, and where the boundary sits between a request filter and the broader offerings built around one.

Comparisons rarely state this plainly.

None of these categories fixes an application. A missing authorisation check, an operation that can be replayed, or data returned to whoever asks are properties of your code, and traffic filtering can make them harder to reach without making them absent. Anything promising otherwise is describing a delay rather than a repair, which is the point made under virtual patching.

They also do not decide policy for you. What to allow, what to refuse, and what to watch first are choices, and the discipline for introducing them without breaking anybody is under operations.

And none of them removes the need to know your own traffic. Every category works from what it observes, so a defence configured against an idea of your traffic rather than the traffic itself will be wrong in ways nobody notices until it refuses something that mattered.