What is a Web Application Firewall?

Network firewall vs WAF

A traditional network firewall operates at OSI layers three and four — IP addresses, ports, TCP state. It does not understand HTTP. A WAF operates at layer seven — it parses the actual request, looks at headers, body, query parameters, and the response, and applies rules against that content. A network firewall blocks the wrong port; a WAF blocks the wrong shape of request to the right port.

What a WAF actually blocks

WAFs are good at three categories of attack. Generic injection attempts — SQL injection patterns, cross-site scripting payloads, command injection probes — that match well-known signatures. Bot and scraping traffic — high request rates, suspicious user agents, headless browser fingerprints. And volumetric or application-layer DDoS — request floods that look abnormal at the rate or path level.

WAFs are weak against bespoke attacks and business-logic flaws. A request that exfiltrates another tenant's data through your own API by hitting GET /api/invoices/123 looks like a normal request — there is no signature for "this user should not have access to that record." That kind of vulnerability has to be fixed in the application code.

Deployment modes

WAFs deploy in three modes. Reverse proxy: traffic flows through the WAF as a separate gateway, which gives full inspection but adds latency and a hop. Embedded module: the WAF runs inside your web server or app server (ModSecurity inside nginx is the classic example), avoiding the extra hop but coupling the WAF to your deployment. CDN-integrated: Cloudflare and AWS WAF run the rule engine at the CDN edge, which is operationally the simplest and the dominant pattern for modern apps.

The big WAF vendors

Cloudflare and AWS WAF dominate the commodity end. Akamai, Imperva, F5, and Fastly Next-Gen WAF (acquired from Signal Sciences) sit in the enterprise tier with deeper rule engines and managed services. ModSecurity is the long-standing open-source option, often deployed with the OWASP Core Rule Set as a base ruleset. Different vendors balance false-positive rate against coverage differently — there is no single right answer.

At QUANT LAB

Every customer-facing app we ship runs behind a CDN with a managed WAF — usually Cloudflare or AWS WAF — for the commodity protection it provides. Where the application handles sensitive data, we tune the rules, add custom signatures, and feed WAF logs to detection tooling. But our standing position is that a WAF is the last line, not the first. The real defense comes from secure development practices and regular pentesting of the application itself, validated against the OWASP Top 10 and the broader OWASP ASVS.

The false-positive tax

The dirtiest secret of WAFs is the false-positive rate. A rule set tuned aggressively will block legitimate traffic — a user submitting a long form, an integration partner posting JSON the rules consider suspicious, a security researcher you actually want talking to your app. Every team operating a WAF spends time triaging blocked requests, tuning rules, and adding allowlists. Most managed services give you sensible defaults, but defaults are not a strategy — a WAF you never tune is a WAF that will eventually block your most important customer.