What Is a Web Application Firewall (WAF)?

A network firewall reads IP addresses and ports. It has no idea what is inside the HTTP request riding over port 443. A login form that takes ' OR 1=1-- as a username looks, to that firewall, exactly like a customer signing in. The packet is well-formed, the destination is allowed, so it passes.

A web application firewall (WAF) reads the part the network firewall ignores: the HTTP request body, headers, and parameters. It inspects each request to a web application and blocks the ones carrying SQL injection, cross-site scripting, or other web exploits before they reach the application server. OWASP defines it plainly: a WAF is "an application firewall for HTTP applications" that "applies a set of rules to an HTTP conversation."

This is the layer 7 defense for anything you expose over the web: login pages, REST APIs, e-commerce checkouts, admin panels. As of March 31, 2025, PCI DSS v4.0 Requirement 6.4.2 makes an automated technical solution like a WAF mandatory in front of public-facing web applications that handle cardholder data.

What a WAF Actually Inspects

A WAF sits between clients and a web application, typically as a reverse proxy. Every HTTP and HTTPS request to the application passes through it first. The WAF parses the request, evaluates it against its rule set, and decides: forward, block, or log and alert.

It works at the application layer (OSI layer 7), which is what separates it from a network firewall. A network firewall enforces who can talk to what, by IP and port. It does not parse a JSON body or a URL query string. A WAF does exactly that. It sees that a search parameter contains <script>document.cookie</script> and that a userId field contains a UNION SELECT. To the network firewall, both are just bytes inside an allowed TCP session.

Most WAFs inspect both directions. On the request side they catch attacks coming in. On the response side they can catch data leaving, for example a server error that leaks a stack trace or a response that returns more records than the page should.

The Two Security Models: Negative and Positive

Every WAF rule falls into one of two philosophies. Most deployments run both.

A negative security model (a blocklist) allows everything except known-bad patterns. It ships with signatures for SQL injection strings, common XSS payloads, path traversal sequences, and known exploit tooling. This is fast to deploy and protects every application behind it on day one, but it only stops attacks it has a signature for. Novel payloads and obfuscated variants slip through, and broad signatures generate false positives.

A positive security model (an allowlist) does the opposite: it denies everything except traffic that matches a defined specification of what the application legitimately accepts. You declare that the quantity field is an integer between 1 and 99, that the email field matches an email pattern, that this endpoint only accepts POST. Anything outside the spec is rejected. This is far stronger against unknown attacks but expensive to build and maintain, because the model breaks every time the application changes.

In practice, a WAF runs a negative model for broad coverage and layers a positive model on the few endpoints that handle sensitive data.

How a WAF Decides: Detection Methods

Within those models, WAFs use three detection techniques, usually in combination:

• Signature-based detection. Matches requests against a database of known attack patterns: a specific SQL injection string, a known scanner's user agent, a CVE exploit payload. Precise and fast, blind to anything new.
• Anomaly-based detection. Builds a baseline of normal traffic, then flags deviations: a parameter ten times its usual length, a sudden burst of requests, a request method an endpoint never sees. Catches novel attacks, but tuning the baseline is the hard part and bad tuning means false positives.
• Policy-based detection. Enforces manually written rules specific to your application and risk tolerance: rate limits, geo-blocking, blocking requests that lack an expected header. This is where the positive model lives.

Modern WAFs add reputation feeds (blocking known-malicious IPs and Tor exit nodes), bot management, and increasingly machine learning to score requests. The core decision is still the same: does this request match something I should stop?

Where a WAF Runs: Deployment Models

The detection logic is the same across deployments. Where the WAF physically sits changes latency, cost, and who maintains it.

Cloud-based WAFs dominate new deployments because they require no hardware and the provider keeps the signature set current. Host-based options like the open-source ModSecurity engine still matter where you need the WAF inside the trust boundary or cannot route traffic externally.

What a WAF Stops, and What It Maps To

A WAF's main job is the application-layer attacks in the OWASP Top 10, the consensus list of the most critical web application security risks. The current edition, OWASP Top 10:2025, leads with A01 Broken Access Control and A05 Injection (which folds in SQL injection and the cross-site scripting class). A WAF directly addresses several of these:

• Injection (A05:2025) including SQL injection, where attacker input is interpreted as a database command.
• Cross-site scripting, a form of injection where attacker script runs in a victim's browser.
• Path traversal, command injection, and remote file inclusion.
• Application-layer (layer 7) DDoS, such as HTTP floods that a network firewall cannot distinguish from real traffic.
• Malicious bots, credential stuffing, and content scraping.

As applications shift from rendered pages to APIs, WAFs have extended to inspect JSON and XML payloads and enforce schema rules on API endpoints. That overlap with dedicated API security controls is where most modern WAF feature growth happens.

What a WAF Does Not Stop

A WAF is a perimeter control. It inspects traffic; it does not understand your application's logic.

It cannot stop business-logic abuse: a valid user exploiting a legitimate workflow, like ordering at a price the app should not allow. The request is well-formed and matches no signature. It cannot fix the underlying vulnerability either. A WAF rule that blocks a SQL injection string is a filter in front of insecure code, not a patch for it. Turn the rule off, or find a payload it misses, and the flaw is still there.

It also struggles with attacks it cannot see. End-to-end encrypted payloads it cannot decrypt, and logic flaws that look identical to normal use, are outside its reach. This is why a WAF is one layer, not the whole defense. Runtime application self-protection (RASP), which runs inside the application and sees whether a suspicious input actually triggers a vulnerability, has lower false positives for app-layer attacks because it has full runtime context. PCI DSS v4.0 names both WAF and RASP as acceptable ways to meet Requirement 6.4.2. Most teams deploy the WAF first because it protects every application behind it without touching code.

WAF vs. Network Firewall vs. NGFW

These get conflated. They operate at different layers and answer different questions.

An NGFW adds application awareness and intrusion prevention to a network firewall, but it is built to secure a wide range of traffic across the network. A WAF is purpose-built for HTTP and HTTPS and goes deep on web-application attacks an NGFW treats only in passing. They are complementary: the network firewall and NGFW handle network security at the perimeter, while the WAF guards the web application itself. Serious environments run all three.

Operating a WAF: The Real Work

Buying a WAF is the easy part. The work is tuning.

Start in detection or log-only mode. Let the WAF watch real traffic and record what it would block, without blocking anything. Review those events, separate true attacks from false positives, then write exceptions for the legitimate traffic the rules flagged. Only then switch to blocking, and only on the rules you trust. A WAF dropped straight into blocking mode with default rules will break legitimate functionality and train your team to ignore it.

Keep the signature set current. Feed WAF logs into your monitoring so blocked attacks become alerts and not just silent drops. And remember the WAF is a layer over the application, never a substitute for fixing the code underneath.

Frequently Asked Questions

What is a web application firewall (WAF)?

A web application firewall is a security control that inspects HTTP and HTTPS traffic to and from a web application and blocks malicious requests such as SQL injection and cross-site scripting. It operates at the application layer (OSI layer 7), filtering the content of web requests rather than just network addresses and ports.

What is the difference between a WAF and a network firewall?

A network firewall works at layers 3 and 4, deciding whether a source IP and port are allowed to connect. It cannot read the content of an HTTP request. A WAF works at layer 7 and inspects the actual request, so it can catch a SQL injection or XSS payload inside an otherwise allowed connection. They protect different layers and are used together.

Does a WAF protect against the OWASP Top 10?

A WAF directly addresses several OWASP Top 10:2025 risks, especially A05 Injection (including SQL injection and cross-site scripting) and application-layer DDoS. It does not cover all ten. Risks rooted in business logic or design, such as broken access control or insecure design, need fixes in the application itself.

What are the main WAF deployment models?

The three models are network-based (a hardware appliance on-premises), host-based (a software module inside the application server, such as ModSecurity), and cloud-based (a managed service in front of the application, such as AWS WAF or Cloudflare). Cloud-based deployments are the most common for new applications.

What is the difference between a blocklist and an allowlist WAF model?

A blocklist (negative security model) allows all traffic except known-bad patterns, so it is quick to deploy but misses novel attacks. An allowlist (positive security model) denies all traffic except what matches a defined specification of legitimate input, which is stronger against unknown attacks but harder to build and maintain. Most WAFs run both.

Is a WAF required for PCI DSS compliance?

PCI DSS v4.0 Requirement 6.4.2, enforced as of March 31, 2025, requires an automated technical solution in front of public-facing web applications that continually detects and prevents web-based attacks. A WAF satisfies this requirement; RASP is the other accepted option. Manual review alone is no longer sufficient.