What Is a Web Application Firewall (WAF)?

The network firewall on the edge sees a clean HTTPS session on port 443 and lets it through, because that is what it was built to do. The request inside that session carries a SQL statement in the search box, and nothing between the internet and the app has read it. A web application firewall (WAF) is the control that reads it, and this post covers what a WAF is, how it decides, where it fails and when a small business needs one.

TL;DR

• A WAF inspects HTTP and HTTPS requests at layer 7 and blocks the ones that look like attacks on the application: injection, cross-site scripting, request smuggling, scanner traffic. A network firewall works on addresses, ports and connection state, and never reads the request.
• The open rule set behind many WAFs is the OWASP CRS. It scores each request instead of blocking on the first match, and a paranoia level setting decides how aggressive it is.
• A WAF covers the input-handling part of the OWASP Top 10. It does not fix broken access control, bad crypto or a supply chain problem, and it cannot see a logged-in user doing something they are allowed to do.
• Three ways to run one: a cloud WAF in front of your DNS (Cloudflare, AWS WAF, Azure WAF), an engine on your own reverse proxy (ModSecurity, Coraza) or an appliance. Cloud is the usual answer for a small team.
• Start every WAF in detection mode. The first two weeks of logs are mostly your own forms, your own scanner and your own integrations. Tune those away, then switch to prevention.

What a WAF Is, and Where It Sits

A web application firewall is a filter that sits between the internet and a web application and inspects every HTTP request before the application sees it. It reads the URL, the headers, the query string, the cookies and the body of the request, and it applies rules that describe what an attack looks like. If a request matches enough of those rules, the WAF drops it and returns an error, usually a 403.

That position matters. A WAF is a reverse proxy, or runs inside one. Traffic reaches the WAF first, the WAF forwards the clean requests to the origin server, and the origin only ever hears from the WAF. For a cloud WAF this means pointing your DNS at the provider. For an on-box WAF it means a module inside nginx, Apache or Caddy on the proxy you already run.

OWASP describes the main job in one line in its virtual patching cheat sheet: a security policy enforcement layer which prevents and reports the exploitation attempt of a known vulnerability. The code behind the WAF stays as it was. The exploit does not reach it. That is the whole idea, and it is why a WAF gets bought on a Friday when a vendor publishes a CVE for the customer portal and the fix is two sprints away.

This is also where a WAF stops being magic. It can only judge what is in the request. If the attack is a valid request from a valid user who should not have been allowed to make it, the WAF has nothing to match on. Hold that thought for the section on what it misses.

The Relative Security explainer is a short, vendor-neutral walkthrough of the same idea with a diagram or two:

WAF vs Network Firewall

The two share a word and almost nothing else. A network firewall decides on layer 3 and 4 facts: source address, destination address, port, protocol, and whether a packet belongs to a connection it has already seen. Our post on the stateful firewall covers how that connection table works and what breaks it. A WAF decides on layer 7 facts: what the HTTP request says.

Here is the practical difference. Your network firewall allows TCP 443 to the web server, because the web server has to be reachable. Every attack on the web application arrives on TCP 443, inside TLS, looking exactly like a customer. The network firewall is doing its job and passing it. The WAF is the control that terminates the TLS, reads the request and asks whether a search parameter should contain UNION SELECT.

They are not alternatives. A web server with a WAF and no network firewall still has every other port open to the world. A web server with a network firewall and no WAF has port 443 open to every payload on earth. The stateful vs stateless post is a good companion if the connection-state half of this is new.

A next-generation firewall muddies the picture, because many of them bundle an intrusion prevention module that inspects some application traffic. That module is a signature engine for known exploits across many protocols. A WAF is built around HTTP, understands parameters, cookies and sessions, and lets you write rules about your own application's fields. If your only public asset is a vendor-hosted SaaS login, the NGFW module may be enough. If you host a customer portal, it is not.

How a WAF Decides: Rules, Scores and Paranoia

A WAF is a rule engine, and the rules it runs decide whether it is useful or just slow. The best-known open rule set is the OWASP Core Rule Set (CRS), which the project describes as a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. Version 4.29.0 is current and 4.25.1 is the long-term support release, as of October 2026. It covers SQL injection, cross-site scripting, local and remote file inclusion, PHP and Java code injection, server-side template injection, shell injection, session fixation, scanner and bot detection, and leaked error data.

CRS does not block on the first match. It uses anomaly scoring, which the project also calls collaborative detection. Each rule that matches adds points to a running score for the request. In the CRS defaults, a critical match adds 5, an error 4, a warning 3 and a notice 2, and the request is blocked when the score reaches the inbound threshold. The default threshold is 5, so one critical rule is enough on its own, while a single protocol warning is not. Azure's WAF documents the same table and the same threshold of 5.

The reason for scoring is false positives. A rule that fires on a single apostrophe would block every customer called O'Brien. A rule that adds 2 points for the apostrophe and only blocks when two other things also look wrong is a rule you can live with.

The second dial is the paranoia level. CRS ships four. In the project's own words, paranoia level 1 provides a set of rules that hardly ever trigger a false alarm, and it is the level for everybody running an HTTP server on the internet. Level 2 is adequate when real user data is involved, perhaps an off-the-shelf online shop, and you should expect to tune false positives. Level 3 is online banking level security with lots of false positives. Level 4 is for the crown jewels and comes with a warning that tuning it could take many weeks.

Cloud WAFs wrap the same machinery in their own terms. Cloudflare's OWASP Core Ruleset is its implementation of CRS 3.3.0 with a threat score and a configurable threshold, and its own documentation (updated June 2026) says the OWASP set is prone to false positives and offers only marginal benefit on top of the Cloudflare Managed Ruleset. Azure WAF on Application Gateway runs CRS 3.2 and newer with a custom-rules layer in front. AWS WAF uses web ACLs with rules that allow, block, count, or send a CAPTCHA or silent challenge.

The pattern is the same everywhere: a managed rule set the vendor maintains, a scoring threshold you can move, and a custom-rules layer where you write the rules that only make sense for your app.

This beginner's guide walks through the request flow and the rule logic at a slower pace than the paragraphs above:

What a WAF Blocks, and What It Does Not

The fair way to size a WAF is against the OWASP Top 10, because that is the list vendors quote. The 2025 edition runs: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging and Alerting Failures, A10 Mishandling of Exceptional Conditions.

A WAF is strong on A05. Injection is the category it was invented for, and SQL injection, command injection and cross-site scripting are the signatures every rule set carries. It helps with parts of A07, because rate limiting and bot rules slow credential stuffing, and it helps with A09, because a WAF log is a record of attack attempts you would otherwise never see. It also covers a slice of A02 by blocking scanner traffic and probes for exposed admin paths.

It does little for the rest. Broken access control, the number one risk, is a request from a logged-in user for a record they should not see. The request is well-formed. Nothing in it looks like an attack. The WAF passes it. Cryptographic failures live in configuration and code. Supply chain failures are a dependency you installed. Insecure design is a flaw in what the app is meant to do. A WAF reads requests; it cannot read intent.

Two more gaps are worth saying out loud. A WAF only protects what is routed through it, so an API the team stood up on a different hostname last quarter is unprotected until someone notices. And a WAF only knows about attacks that look like attacks. Verizon's 2025 Data Breach Investigations Report puts exploitation of vulnerabilities at 20 percent of initial access, up 34 percent on the previous year, with much of that growth in edge devices and VPNs rather than web forms. A WAF in front of the portal does nothing for the VPN appliance next to it.

So the right mental model is narrow and useful: a WAF buys time against known request-shaped attacks on the apps you point it at. It is a layer, not a replacement for patch management, code review or access control. Our post on what an exploit is covers the patch window a WAF is meant to bridge.

Three Ways to Deploy One

There are three places a WAF can live, and for a small team the choice is mostly about who runs it.

Cloud WAF. You point the domain's DNS at the provider, the provider terminates TLS at its edge, inspects the request and forwards it to your origin. Cloudflare, AWS WAF and Azure WAF all work this way, and so do the CDN-attached WAFs from Akamai, Fastly and Imperva. Managed rules update without you, DDoS absorption comes with the edge, and there is nothing to patch. The trade is that the provider sits in your traffic path and sees your plaintext requests, and that your origin has to be locked down so attackers cannot bypass the edge by hitting it directly.

On-box WAF. An engine inside the reverse proxy you already run. ModSecurity is the original: version 3 is a library with connectors for nginx and other servers, and the version 2 Apache module is still maintained. Coraza is the newer engine, written in Go under an Apache 2.0 licence, with a stable Caddy plugin and an Envoy extension, and experimental connectors for HAProxy, Traefik and nginx. Both run the OWASP CRS. The trade is that you own the tuning, the logs and the memory footprint, and the first question in any r/sysadmin thread about them is which dashboard to use.

Appliance or virtual appliance. A dedicated box or VM in your data centre from F5, Fortinet, Barracuda or similar, usually bought because the application cannot be exposed through a third party, or because the team already runs that vendor's firewalls. More control, more cost, and the latency question goes away because it sits next to the app.

The latency question is the one that comes up when the application is on-premises and the WAF is in the cloud. Every request makes a round trip to the provider's nearest point of presence and back. For a customer portal that is milliseconds on a path that already crosses the internet. For an internal app with users in the same building, it can be the difference between snappy and noticeably slower, and that is the case for an on-box engine.

This January 2026 thread is a typical buying conversation: a team on Imperva asking whether Cloudflare's WAF is better, with certificate limits and support quality as the pain points rather than detection.

And this May 2026 thread is the on-box version of the same decision: an admin moving to pfSense and HAProxy, looking at Coraza as a lighter ModSecurity, and asking the question that decides most on-box deployments, which is how to see the blocks without reading raw logs.

Whichever route you pick, the origin lockdown is not optional. A cloud WAF protects nothing if the origin server still answers to anyone who knows its IP address. Restrict the origin's inbound rules to the provider's published address ranges, or use an authenticated tunnel, and the attack surface shrinks to the one path you are inspecting.

Detection Mode First

Every WAF has two modes, and the order you use them in decides whether the project survives its first week. Azure calls them detection and prevention, and its own guidance is to run a newly deployed WAF in detection mode for a short period in production, collect the logs and write the exceptions before switching. Cloudflare's rule sets ship with some rules disabled by default for the same reason. CRS has a detection-only setting in its setup file.

The first fortnight of detection logs tells the same story on almost every deployment. The top matches are not attackers. They are the marketing team's form builder posting HTML, the monitoring tool hitting the health endpoint with an empty user agent, the vulnerability scanner you pay for, and one integration that sends JSON with a content type the rule set does not expect. Each of those is a false positive to tune away with a rule exclusion, and each one you skip is a customer locked out of checkout on day one of prevention mode.

A workable rollout for a small team fits in four weeks:

Two habits keep it working. Send the WAF logs to wherever the rest of your log management goes, so a spike in blocks shows up next to the other signals. And re-run the detection exercise after any big application change, because a new form field is a new false positive.

The log review also pays for itself in a way nobody budgets for. A WAF log is the first place an incident shows up as a pattern: the same source, the same path, the same payload, hour after hour. That is the input your incident response plan needs, and it arrives for free once the WAF is in place.

What Tuning Looks Like

Tuning is the work of telling the rule set which of its matches are wrong for your application, and it is the part the sales deck skips.

A rule exclusion is a rule that switches another rule off, either everywhere or only for one parameter or one path. The classic case is a rich-text field. The CRS cross-site scripting rules will match the HTML a content editor pastes into a blog body, every time, and the fix is an exclusion that says: on POST /admin/posts, ignore rules 941100 through 941999 for the body parameter. The rule set stays intact for every other field on the site.

Three rules of thumb keep tuning sane. Exclude by parameter and path, never globally, or you are switching the WAF off one rule at a time. Keep the exclusions in version control next to the proxy config, because they are the only record of why the WAF behaves the way it does. And stay at paranoia level 1 until level 1 is quiet, because every level above it multiplies the exclusions you have to write.

Cloud providers add a second detection layer on top of signatures. Cloudflare's attack score is a machine learning classifier that rates each request from 1 to 99 on how likely it is to be malicious, aimed at payloads that have been fuzzed enough to dodge an exact signature match. It is an Enterprise feature, with a single summary field on the Business plan, and the vendor's own recommendation is to run it alongside managed rules rather than instead of them.

When a Small Business Needs One

The question is rarely whether a WAF helps. It is whether this business has anything a WAF would protect, and whether the team can run it.

The cases that call for one are specific. You host a web application with a public login, a customer portal, a booking system, an online shop, or a self-hosted tool like a ticketing system or a wiki. You run a vendor application you cannot patch on your own schedule, so a published CVE leaves you exposed until the vendor ships. You take card payments on your own pages, where PCI DSS v4.0.1 Requirement 6.4.2 (mandatory since 31 March 2025) calls for an automated technical solution that continually detects and prevents web-based attacks on public-facing web applications, which in practice means a WAF. Or your cyber insurance renewal asks the question, and the answer today is no; our guide to cyber insurance requirements covers how those questionnaires are scored.

The cases that do not call for one are just as clear. If every application the business uses is SaaS hosted by the vendor, the vendor runs the WAF and you have nothing to put one in front of. If the only public web presence is a brochure site on a managed platform, the platform's included protection is enough. And if nobody on the team will read the logs, a WAF in detection mode forever is a monthly fee for a report nobody opens.

A short inventory settles it. List every hostname that resolves to something you run, and every port 80 or 443 listener on servers you manage. OpenFrame can run that listener check as a script across a client's devices and collect the output, which is one way to find the forgotten test server. Anything on that list with a login or a form is a candidate. Anything that only serves static pages is not.

Cost follows the route. Cloud WAFs start inside the free or lowest tiers of the big providers and climb with features such as bot management and the machine learning scores. On-box engines are free software plus the hours to tune them. Appliances are a capital line and a support contract. For a small business with one or two public apps, the cloud tier that includes managed rules and rate limiting is usually the right first purchase, with the budget going to the person who reads the logs rather than to the licence.

The Short Version

A WAF reads HTTP requests and blocks the ones that look like attacks on the application. A network firewall never reads them, so the two are layers, not alternatives. The open rule set behind most of them scores each request instead of blocking on the first match, and the paranoia level decides how aggressive it is. It covers injection and scanner traffic well, and it cannot see broken access control, bad crypto or a supply chain problem. Pick a cloud WAF unless you have a reason not to, lock the origin down, run two weeks in detection mode, tune your own traffic out, then switch to prevention. Then make someone own the log.

If you are placing a WAF in a wider plan, the network penetration testing post covers how a tester will probe what the WAF leaves open, and the DDoS attack post covers the volumetric side that a cloud WAF's edge absorbs and an on-box engine does not.

FAQ

What does WAF stand for?

WAF stands for web application firewall. It is a filter that inspects HTTP and HTTPS requests at the application layer and blocks requests that match attack patterns such as SQL injection or cross-site scripting, before they reach the web server.

Is a WAF the same as a firewall?

No. A network firewall decides on IP addresses, ports, protocols and connection state, and never reads the content of an allowed session. A WAF reads the content of each HTTP request. A web server needs both: the network firewall to close every port except the web ports, and the WAF to inspect what arrives on those.

Does a WAF stop all OWASP Top 10 attacks?

No. It is strong on injection and cross-site scripting, helps with credential stuffing through rate limiting, and gives you a log of attack attempts. It does not fix broken access control, cryptographic failures, supply chain failures or insecure design, because those are not visible in the shape of a request.

Will a WAF slow my website down?

A cloud WAF adds a round trip to the provider's nearest edge, which is milliseconds for internet-facing users and often offset by the provider's caching. An on-box engine adds inspection time on the proxy, which is small at paranoia level 1 and grows with the rule count. The slowdown people notice is a false positive blocking a form, not latency.

Do I need a WAF for a WordPress site?

If the site is hosted on a managed platform that includes its own protection, usually not. If you host it yourself, with plugins, a login page and a contact form, a cloud WAF with managed rules and rate limiting on the login path is a cheap layer that blocks the automated scanning every exposed WordPress site attracts.

How long does it take to tune a WAF?

Plan on two weeks in detection mode for a typical business application at paranoia level 1, with a daily look at the matched rules. Higher paranoia levels add weeks, and the CRS project's own guidance is that level 4 could take many weeks to tune. Re-check after any major release, because new form fields create new false positives.