A traditional firewall and a web application firewall solve different problems, despite the shared name. Knowing the difference matters for understanding what’s actually protecting a web application, and what isn’t.

Network firewalls versus web application firewalls

A traditional network firewall filters traffic based on network-level information — source and destination IP addresses, ports, protocols — similar in spirit to the layer 4 load balancing distinction covered elsewhere on this site. It has no visibility into what an HTTP request actually contains.

A web application firewall (WAF) operates at the application layer instead: it inspects the actual content of HTTP requests — URL parameters, headers, request bodies — looking for patterns associated with known attack techniques, and blocks or flags requests that match. OWASP’s overview of web application firewalls and AWS’s WAF documentation both describe this application-layer inspection as the defining characteristic that separates a WAF from a conventional network firewall.

What a WAF actually looks for

A WAF’s rules typically target a specific, well-known set of attack categories, including:

  • SQL injection — malicious database query fragments smuggled into input fields, designed to manipulate a backend database into returning or modifying data it shouldn’t.
  • Cross-site scripting (XSS) — malicious script content injected into a request in a way designed to later execute in another user’s browser.
  • Known vulnerability patterns — request signatures matching publicly disclosed vulnerabilities in common software components.
  • Volumetric and bot-like request patterns — unusually high request rates or automated-looking traffic that may indicate abuse, which connects directly to the DDoS mitigation role a WAF often plays as part of a broader defense.

Where a WAF typically sits

A WAF is commonly deployed at the edge of an architecture — often integrated with a CDN or load balancer, discussed in What Is a CDN? — so that malicious requests are filtered out before they ever reach the application or its backend. This positioning matters: the earlier a bad request is stopped, the less of the system’s own capacity it consumes trying to process it.

What a WAF doesn’t do

A WAF filters based on known attack patterns, which means its effectiveness depends heavily on its rule set staying current, and it can miss genuinely novel attack techniques that don’t match any known signature. It also doesn’t fix an underlying application vulnerability — it’s a mitigating control in front of the application, not a substitute for writing secure code, validating input properly, and keeping dependencies patched. A WAF reduces the chance a known attack pattern reaches a vulnerable endpoint; it doesn’t make the endpoint itself not vulnerable.

Key takeaway

A web application firewall inspects the actual content of HTTP requests for known attack patterns, filtering out threats like SQL injection and cross-site scripting before they reach an application — a fundamentally different job from a network firewall’s IP-and-port-level filtering. It’s an important layer of defense, best understood as a mitigating control that reduces exposure, not a replacement for secure application code.

This article explains general web security concepts; specific WAF rule sets and capabilities vary by provider. See our disclaimer.