What Is a WAF? Web Application Firewalls Explained

A WAF sits in the request path, usually as a reverse proxy: clients connect to the WAF, the WAF connects to the application, and every request and response passes through it. Because most traffic is encrypted, that position requires terminating TLS, which is precisely what makes application-layer inspection possible and also what makes certificate management part of the deployment. Some products operate out of band or as a plugin inside the web server instead, trading enforcement capability for a simpler traffic path.

For each request the WAF normalizes the input — decoding URL encoding, unicode escapes, and other transformations attackers use to disguise a payload — then evaluates it against its policy. A match produces an action: block with an error page, allow but log, challenge the client, redirect, or rate-limit the source. Good products also inspect the response, which catches error messages leaking stack traces or database internals, and in some cases catches data leaving that should not be.

Two operating modes matter for planning. Detection or monitoring mode logs what would have been blocked and blocks nothing; blocking or prevention mode enforces. Nearly every deployment starts in monitoring mode, because a rule set applied blind to a real application will block legitimate traffic on the first day. The gap between the two modes is where the actual work of owning a WAF happens.

A traditional network firewall works at the network and transport layers, matching on addresses, ports, protocols and connection state. It is the right tool for deciding which systems are reachable from where, and it is blind by design to what is inside an allowed session. A next-generation firewall narrows the gap by identifying applications and inspecting some content, but its application awareness answers a different question — which application is this traffic, and should this user run it — rather than whether this specific request to your own web application contains an injection payload.

A WAF is purpose-built for the second question and knows things a general-purpose device does not: how HTTP parameters are structured, what a session cookie is, how a JSON body or a GraphQL query is shaped, what a normal request to a given endpoint looks like. That specificity is why the two are complements rather than alternatives. The network firewall controls exposure; the WAF controls what may be said to the things left exposed.

The related term worth separating is RASP, runtime application self-protection, which instruments the application itself so protection runs inside the process with full visibility into how input is actually used. RASP produces far fewer false positives than external pattern matching because it sees the consequence rather than guessing from the request, at the cost of language-specific agents and a performance overhead inside the application. Compliance frameworks that require an automated technical solution generally accept either.

Most WAFs run a negative security model by default: a library of signatures and heuristics describing known attack patterns, with everything else allowed. The reference implementation is the OWASP Core Rule Set, a free, vendor-neutral rule set that most commercial products either bundle, adapt or compete against. CRS version 4 introduced a plugin architecture, configurable reporting levels and earlier blocking decisions, and removed the dependency on PCRE so the rules run on engines other than the original. CRS uses anomaly scoring rather than blocking on a single match — each matching rule contributes to a score, and the request is blocked when the total crosses a threshold — which is what lets an operator tune sensitivity without disabling rules individually.

A positive security model inverts this: define what a valid request to each endpoint looks like — which parameters exist, their types, their length limits — and reject everything else. It is dramatically more effective against novel attacks and dramatically more work to maintain, because every application change invalidates part of the model. Products that offer it usually learn a baseline automatically from observed traffic, which helps and does not eliminate the maintenance. Mature deployments frequently run both: a positive model on the handful of endpoints that matter most, and rule-set-based detection everywhere else.

Two operational facts belong in any evaluation. First, rule sets need updating, and the update path — who ships new signatures, how often, and whether it costs extra — is a licensing question worth asking early. Second, the open-source engine landscape has shifted: ModSecurity, the long-standing engine most open rule sets were written for, moved from Trustwave to OWASP in January 2024 with sponsorship continuing into that year, and alternative engines have grown up around the same rule format. If a deployment is built on open-source components, confirm which engine and which rule-set version it actually runs, and what the support horizon for both looks like.

A WAF is strong against attacks visible in the shape of a request. Injection attempts — SQL, command, template — path traversal, cross-site scripting payloads, malformed protocol abuse, credential-stuffing and enumeration by rate, scraping and much automated scanning are all things a well-tuned WAF handles well. It is also genuinely valuable as a virtual patch: when a vulnerability is disclosed in a framework or a component and the fix cannot ship for two weeks, a targeted rule can block the exploit path in hours. That buys time, which is often the entire value proposition during an incident.

It is weak, or blind, against flaws that live in the application's own logic. The OWASP Top 10:2025 places broken access control at number one — the same position it held in 2021 — and broken access control is exactly the class a WAF cannot see. A request from an authenticated user for a record belonging to a different customer is a perfectly well-formed request; nothing in its structure signals that the application should have refused it. The same limitation applies to business-logic abuse, to insecure design, and to most of what an attacker does after they are legitimately inside a session.

Two other categories on that list are similarly out of reach. Security misconfiguration, which moved up to second place in the 2025 revision, is a property of how systems are set up rather than of the traffic reaching them. Software supply chain failures, added as a new category in 2025, concern what is inside the application's dependencies. A WAF may block the exploitation of a vulnerable component if the exploit is recognizable in a request, and it does nothing about the component being there. The correct framing is that a WAF reduces exposure while the underlying defects are fixed — it is a control in front of the application, not a substitute for securing it.

Four models are in common use. A hardware appliance sits in the data center in front of the application servers, giving full traffic control and predictable latency, and requiring rack space, power and capacity planning. A virtual appliance is the same software as a virtual machine, which suits virtualized data centers and cloud environments and keeps the traffic inside the tenancy. A cloud or CDN-delivered WAF operates in the provider's network, filtering traffic before it ever reaches the origin, which brings distributed-denial-of-service absorption with it and moves TLS termination outside the organization's control. A host-based or embedded WAF runs as a module inside the web server, which costs nothing to place and scales with the servers themselves.

Sizing follows requests rather than raw bandwidth: requests per second at peak, concurrent connections, the size of typical request bodies, and above all whether TLS termination and full body inspection are enabled, both of which are expensive. Latency added per request is the figure to insist on under realistic conditions, because vendor figures are usually measured with minimal rule sets and no inspection of bodies. For a cloud-delivered service, the meter is normally requests and bandwidth, which makes cost a function of traffic volume including the attack traffic — worth modelling before an incident rather than after.

Licensing is where the surprises are. Rule-set updates, bot management, API protection, distributed-denial-of-service mitigation and advanced analytics are frequently separate line items rather than included capability, and the difference between a base licence and a usable configuration can be substantial. Budget the operating cost as well: a WAF is not a device that is installed and left, and the tuning effort in the first quarter is real work by someone who understands both the rule set and the application.

The clearest requirement is in the payment card standard. PCI DSS 4.0 requirement 6.4.2 obliges organizations to deploy an automated technical solution in front of public-facing web applications that continually detects and prevents web-based attacks. It became mandatory on 31 March 2025, replacing the previous requirement 6.4.1, which had allowed periodic manual vulnerability review as an alternative. That option is gone: an automated control — a WAF, or RASP — is now the expectation for any public-facing web application in a cardholder-data environment.

Elsewhere the requirement is expressed as an outcome rather than a product. Federal control catalogs describe boundary protection and input-validation controls that a WAF is one reasonable way to implement, and assessors generally look for evidence that web-facing applications are protected and monitored rather than for a specific technology on an approved list. The practical consequence is the same either way: for a public-facing application handling regulated data, be prepared to explain what inspects the traffic and how its findings are reviewed.

One compliance-driven failure pattern is worth naming. A WAF deployed to satisfy an auditor and left permanently in logging mode satisfies nobody: it produces the evidence of deployment and none of the protection, and an assessor who asks whether it blocks will get an answer nobody wants to give. Reaching blocking mode on the traffic that matters is the point of the exercise, and the tuning time that requires belongs in the project plan alongside the purchase.