WAF vs firewall: two different questions entirely

The row that matters most is the fourth. Each is blind to what the other is built for, which is why "do I need both" is usually the wrong question and "which of these does my current problem live in" is the right one. Asked that way, most situations answer themselves in a sentence.

It is the tool for reachability.

A database that should never be reachable from outside, an administrative port exposed by a default configuration, an internal service that ended up with a public address: these are decided by address and port, and they are decided before anything about the content matters. In each case the right outcome is that the traffic never establishes a connection at all, which is a cleaner result than inspecting whatever it would have sent. A request filter placed in front of them would inspect requests that should never have arrived at all.

It also fails cleanly, which is underrated. Traffic is either permitted to reach a port or it is not, and the rule that produced the outcome is findable afterwards. Compared to content matching, where a decision depends on what a pattern happened to match, the reasoning is simple enough to audit and to explain to somebody who was affected by it.

The trade is that it cannot help once traffic is arriving somewhere it is supposed to arrive, which is most of what a public site consists of.

It is the tool for meaning.

Once traffic is legitimately arriving at a service that should be reachable, every remaining question is about what is being asked rather than about who is allowed to ask. Injection attempts arrive on the port you deliberately opened. Abuse of an expensive endpoint arrives as ordinary well-formed requests. Automated traffic hammering a form uses exactly the interface you published on purpose.

None of that is visible at the network level, because at that level all of it looks identical to the traffic you want: the same port, the same protocol, and often the same addresses as legitimate users. What separates it is the content and the pattern across several requests, and separating on those is precisely what a request filter exists to do. The types of attack this covers, and where the boundary sits, are set out under attack layers.

Neither sees what the other is built for, and there is a third gap they share. Knowing the gaps is more useful than knowing the features, because a gap is where an expectation quietly fails rather than where a comparison table puts a mark.

Neither one repairs an application. A missing authorisation check is not a network property and not a request property; it is a property of the code, and both categories can only make it harder to reach rather than absent. That distinction is the one to carry into any vendor conversation, because it is the one most often blurred, usually by describing filtering as protection rather than as distance.

Volumetric traffic that saturates a link before arriving is also outside both: a firewall drops it after it has already consumed the capacity it was sent to consume, and a request filter never sees it at all. That belongs to a different layer entirely, covered under attacks, and it matters because both categories are routinely credited with handling it.

The verdict, stated as directly as the question deserves. Nothing below depends on which product you buy; it depends only on which of the two questions you currently have, and that is knowable before any purchase.

Use a network firewall when the question is reachability. Something is listening that should not be, or something is reaching a port it has no business reaching. Nothing about request content is involved.

Use a request filter when the question is content. The service should be reachable, is reachable, and is receiving requests you would rather it did not have to handle. Closing the port is not an option here, because closing it would remove the service along with the problem.

Use both when you have both questions, which most sites eventually do. They are not layered versions of one another and do not overlap enough to substitute for each other: running one does not reduce what the other is for, and no configuration of either extends it into the other's territory.

Use neither as a substitute for fixing what is broken. Both are ways of keeping traffic away from a problem rather than ways of removing it, and the discipline for introducing either without breaking legitimate users is under operations. That discipline matters more for the request filter, since its mistakes look like your site being broken rather than like a connection being refused.