WAF vs Firewall: What Does Each One Actually Inspect?

A network firewall decides which connections may reach a system, based on addresses, ports and connection state. A web application firewall (WAF) reads the HTTP conversation itself and applies rules aimed at web attacks such as SQL injection and cross-site scripting. They solve different problems, and one does not replace the other.

What does a network firewall look at?

NIST SP 800-41 Rev. 1 describes firewalls as tools that govern traffic between networks or hosts with different security levels, and covers packet filtering, proxies and host-based firewalls. A classic packet filter looks at source and destination address, port and protocol. A stateful one also tracks whether a packet belongs to an established connection.

That is enough to say "the internet may reach port 443 on the web server and nothing else." It is not enough to say anything about what is inside the request on port 443. To a packet filter, a normal page view and an attack string look the same: both are valid HTTPS traffic to an allowed port.

What does a WAF look at?

OWASP describes a WAF as an application firewall for HTTP applications that applies a set of rules to an HTTP conversation. Those rules typically target common attacks like cross-site scripting and SQL injection. A WAF protects servers rather than clients, sits in front of specific web applications, and can be thought of as a reverse proxy. It may be an appliance, a server plugin or a filter.

Because a WAF works on HTTP, it can see the URL, headers, cookies and body, once TLS has been terminated at or before the WAF. It can block a request whose parameter contains a SQL fragment, or limit how often one client may hit a login endpoint.

OWASP also notes that a WAF often needs customization, and that this has to be maintained as the application changes. That is the cost most teams underestimate.

Where does each one stop?

Here is a constructed example. A shop runs a checkout app behind a firewall that allows only port 443. A developer adds a search endpoint that builds a database query by string concatenation.

The firewall sees nothing wrong, since the traffic is allowed. A WAF with a rule for SQL injection may block the obvious probes. But the flaw is still in the code. A request shaped to evade the rule, or a flaw that is not a known attack pattern, such as a missing authorization check on an order ID, passes straight through. A WAF cannot know that user 41 should not read order 42, because that rule lives in the application.

Neither tool fixes the bug. A WAF buys time and reduces noise; the fix belongs in code.

Which questions does each tool answer?

• Firewall: who may talk to this machine, on which port, from where?
• WAF: is this particular web request shaped like an attack on this application?
• Neither: is this user allowed to do this action on this record?

The third question is answered by application logic, tests and code review, which is why a WAF is one layer rather than a substitute for secure development.

How to check or apply this

1. Draw the path of a request from the internet to your app and mark where TLS ends. A WAF placed after encrypted traffic passes through cannot read it.
2. Confirm the firewall allows only the ports the app needs, and that the app server is not directly reachable around the WAF.
3. Run the WAF in log-only mode first, review false positives for a week, then move to blocking.
4. Assign an owner to update WAF rules whenever the app adds or changes endpoints.
5. Keep a list of findings that the WAF is covering for, each with a ticket to fix the code.
6. Test with your own scanner against staging to see what the WAF blocks and what slips by.

Quick check

Sources

• OWASP, Web Application Firewall
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy

Last reviewed: 18 October 2026.