A WAF is a reverse proxy that inspects the content of every HTTP request before the application sees it. A network firewall decides on addresses and ports, so once port 443 is open it allows everything through.
A WAF reads what is inside those requests and blocks injection, scripting, traversal and the other attacks aimed at the application rather than the network.
- Network firewalls decide on addresses. WAFs decide on content
- It protects code you cannot change, which is the real value
- Start in detection mode, or it gets disabled in week one
- A valid request that should have been refused is invisible to it
- A cloud WAF protects nothing if the origin answers the internet
On this page
The distinctionWhat a network firewall cannot see
The distinction is worth being precise about, because these two security devices get compared constantly and they answer different questions.
A network firewall decides whether traffic is allowed between two points, based on the source address, the destination address, the port, and increasingly which application the traffic belongs to. Once it has decided that HTTPS traffic to a web server is permitted, all the traffic on that connection is permitted.
That decision is correct and it is where the network firewall's job ends. Inside the allowed connection, a web request might be reading a customer database, or it might be a login form. The firewall cannot tell, because both are HTTPS traffic to port 443.
A WAF is a reverse proxy, so it terminates the connection, opens the web request and reads all of it: the URL, the headers, the cookies, the parameters and the body.
That is what lets a WAF recognize a database query hidden in a form field, and it is also what makes layer 7 inspection expensive. Evaluating every request against hundreds of security policies costs far more than checking an address.
The two firewalls are complementary rather than alternatives. The network firewall keeps everything except web traffic away from the server. The WAF decides which of those requests are safe, and protects the application from the rest.
What it stopsWhat WAFs actually block
Most WAF security policies are organized around the OWASP Top Ten, the industry list of the most common web application weaknesses. Named concretely, the threats WAFs genuinely help with are these.
SQL injection, where a malicious request puts database syntax into a form field, so a query intended to look up a username instead returns every row in the table. The classic web application attack and still one of the most common.
Cross site scripting, where an attacker gets malicious JavaScript stored or reflected into a page other users then load, so their browsers run that code with the web application's permissions.
Path traversal, where a malicious request asks for a file outside the intended directory using sequences of dots and slashes, reaching configuration files or credentials on the server.
Command injection, where malicious input reaches a system shell on the server and runs there.
Malicious bots and scraping, where each web request is individually valid and the pattern is not: credential stuffing, inventory scraping, content theft. Most cloud based WAFs include bot management for exactly these threats.
Application layer DDoS attacks, where a small number of expensive web requests exhausts the server without saturating the network. A network device cannot detect that, because the traffic volume looks unremarkable while the application falls over.
API protection, which is now most of the traffic. A modern web application is a browser front end talking to an API, and mobile apps talk to the same API with no browser at all.
The vulnerabilities there are not quite the same list: OWASP maintains a separate API Top Ten, led by broken object level authorization, which is the flaw where changing an ID in a request returns somebody else's data.
A WAF tuned for browser traffic protects an API badly, because it has no idea which fields that API legitimately accepts. WAFs that offer real API protection take a schema, an OpenAPI definition, and enforce it, which is a positive security model by another name and the only thing that works.
Virtual patching, which is the underrated one. When vulnerabilities are announced in web applications you run, a WAF policy blocking the exploit pattern offers protection until the patch can be scheduled. That is genuinely valuable, and it is a bridge rather than a destination.
Vendors say a WAF covers the OWASP Top Ten. Here is what that claim is worth, item by item.
| Weakness | Can a WAF block it | Why |
|---|---|---|
| Injection | Yes | The payload has a recognizable shape |
| Cross site scripting | Yes | Script syntax in a parameter is visible |
| Path traversal | Yes | The dot sequences are a pattern |
| Vulnerable components | Yes, virtually | Rules block the known exploit |
| Security misconfiguration | Partly | Some headers can be added by the proxy |
| Broken authentication | Barely | Rate limits help, the flaw does not show |
| Broken access control | No | The request is well formed |
| Insecure design | No | Nothing about it looks wrong |
| Cryptographic failures | No | It happens inside the application |
The line falls in the same place every time. A WAF sees requests that are malformed or that carry a payload with a shape. It cannot see a perfectly valid request that the application should have refused, and the bottom three rows are exactly that.
Rule modelsThe two security models
All WAFs work one of two ways, and most support both security models.
A negative security model blocks what looks bad. It carries a large signature based policy of known attack patterns, and every web request not matching passes. This is how nearly every WAF deployment starts, because it needs no knowledge of the application.
Its weakness is inherent: it catches known threats, and a determined attacker who studies the policies can construct a request that behaves the same and looks different.
A positive security model allows only what looks right. It carries a description of what the web application legitimately accepts: which URLs exist, which parameters they take, what type and length each one is. Everything else is rejected. This is far stronger and far more work, because that policy has to be built and then maintained as the application changes.
The realistic answer is a negative model with the generic policies on, plus a positive model on the handful of endpoints that matter most: the login form, the payment path, the admin interface. Building a complete positive policy for a large web application is a project that outlives the enthusiasm for it.
DeploymentDeploying a WAF without causing an outage
A WAF in blocking mode can break a working web application, and the deployment order that avoids that is the same everywhere.
Start in detection mode. Run the WAF inline, logging what it would have blocked and changing nothing. Two weeks minimum, longer if the web application has a monthly cycle.
Read the log and tune the policies. The findings will be mostly false positives, and they are informative: a rule triggering on a legitimate web request tells you something about how the application uses its parameters. Tune the rule or exclude the path, and record why.
Turn on blocking one policy group at a time. Start with the threats that are unambiguous, injection and traversal, and leave the noisier ones for later.
Watch the error rate, not the WAF console. The measure of a bad deployment is customers failing to complete an action, and that shows up in the web application metrics before it shows up as a security alert.
Keep an exception path. Somebody needs to move a policy back to detection quickly when it blocks something important at nine on a Monday. If that takes a change ticket, the WAF gets disabled entirely the first time it matters.
Which of the three deployment models you chose changes none of that order. It changes only where the traffic is inspected, which the next section covers.
Where it sitsThe three deployment models
WAFs come in three shapes, and the choice is made early because it decides where your web traffic goes and who holds the data while it is inspected.
Cloud based WAFs are a security service in front of the site. You point DNS at the provider, they reverse proxy the traffic, inspect it, and forward what passes to your origin server.
The security policies are written and updated by the vendor, there is nothing to size or patch, and the same edge network absorbs volumetric DDoS attacks before they reach you. The cost is that your traffic is decrypted on somebody else's infrastructure, and that the protection only applies to requests that actually route through the proxy.
Network based WAFs are an appliance, physical or virtual, in your own data center in front of the web servers. The traffic and the data never leave your infrastructure, the latency is minimal because the device is local, and everything else is yours to run: sizing, patching, high availability, and policy updates.
It is the right answer for regulated data that cannot be decrypted by a third party, and it protects nothing against a volumetric attack, because the flood arrives at your own link.
Host based WAFs run as a module inside the web server itself, ModSecurity being the long standing example. They see the request after TLS termination and after the server has parsed it, which makes evasion harder, and they know exactly which application they are protecting.
The cost is that they consume the same server resources as the application and have to be configured on every host.
Most organizations end up cloud based, and the reason is not technical. A cloud based WAF is the only one of the three where somebody else maintains the security policies as new attacks appear, and keeping a policy set current is the work that quietly does not get done.
The limitsWhat a WAF does not protect you from
This section matters as much as the rest, because WAFs are frequently sold as protecting more than they do.
It does not fix the vulnerability. The flawed code is still there and a WAF policy is a filter in front of it. Anything reaching the web application by another route, an internal caller, a different hostname, a direct connection to the origin server, reaches the vulnerability with no protection at all.
It can be evaded. All WAFs have been bypassed, and the security research is public. Encoding tricks, unusual character sets, splitting a payload across parameters and protocol level oddities all have known techniques. A WAF raises the cost of attacks rather than making them impossible.
It does not understand your business logic. A request that lets a user read another user's order by changing an ID is perfectly well formed. No security signature matches it, because nothing about it is malicious in form. This class of flaw is common in web applications and WAFs are blind to it.
It does not protect an origin server that is reachable directly. A cloud based WAF only sees traffic routed through the reverse proxy. If the origin server's real address is discoverable and accepts connections from anywhere, an attacker goes around the WAF entirely. Restricting the origin to the cloud provider addresses is the step everybody forgets.
It is not a substitute for patching or for secure development. It buys time and protects what you cannot change. Vulnerabilities you can fix should be fixed in the application.
PitfallsWhere people go wrong
Leaving it in detection mode forever. Very common. The tuning is never finished, blocking is never turned on, and the organization has bought a logging device with a compliance sticker rather than something that protects anything.
Turning on every security policy at once. The web application breaks, the WAF is blamed, and it goes back to detection mode permanently. One policy group at a time, in order.
Not locking down the origin server. A cloud based WAF protects only the path through the reverse proxy. If the origin answers web requests from the whole internet, the WAF is optional from the attacker's point of view.
Treating a blocked request as a stopped attack. It is one stopped malicious request. The same attacker tries again with a different encoding, and the log entry is a signal to look at the web application rather than a result.
Excluding a whole path to fix one false positive. The exclusion outlives the reason and nobody remembers what it was for. Tune the specific security policy, and write down why.
Forgetting that the reverse proxy terminates TLS. A cloud based WAF decrypts your web traffic in order to inspect it, which is a real security consideration for regulated data and a conversation to have deliberately rather than discover later.
ComparisonA WAF, a network firewall and RASP, on what each one can actually see
| Criterion | WAF | Network firewall | RASP |
|---|---|---|---|
| Reads web request content | Yes | No | Yes |
| Understands application logic | No | No | Yes |
| Protects applications and APIs you cannot change | Yes | No | No |
| Needs the application modified | No | No | Yes |
| Blocks by address and port | No | Yes | No |
| Stops malicious SQL injection | Usually | No | Yes |
| Stops business logic abuse | No | No | Sometimes |
| Effort to deploy | Medium | Low | High |
| Required for PCI DSS | Yes, or a code review | Separately | No |
The third and fourth rows are the trade. A WAF sits outside and protects any web application, including software you did not write. RASP runs inside the application and understands what it is doing, and only works where you control the code.
FAQFrequently asked questions
What is a WAF in simple terms?
A firewall that reads the content of web requests rather than just their addresses, and blocks malicious ones aimed at the applications behind it.
How are WAFs different from network firewalls?
Network firewalls decide whether traffic is allowed based on addresses and ports. A WAF works at layer 7, inspecting what is inside the allowed web traffic to decide whether the request itself is an attack.
Does a WAF replace fixing the code?
No. It filters web requests in front of unfixed code, which buys time and offers protection for software you cannot change. The vulnerabilities are still there for anything reaching the application another way.
What is the OWASP Top Ten?
The industry list of the most common web application security weaknesses. Most WAF policies are organized around it, and it is the vocabulary vendors use.
Should a WAF run in blocking or detection mode?
Detection first, for at least two weeks, then blocking one security policy group at a time. Going straight to blocking is how a WAF gets disabled in its first week.
Can WAFs be bypassed?
Yes, and the techniques are public. Encoding, unusual character sets and splitting payloads all work against signature based policies. A WAF raises the cost of an attack rather than removing the threat.
Cloud based WAF or an appliance?
Cloud based for most organizations: no hardware, security policies maintained by the vendor, and the proxy absorbs DDoS attacks before they reach your server. A network based appliance where the web traffic must stay inside your own infrastructure.
Does a WAF stop DDoS attacks?
Application layer floods, yes, which are the kind a network device cannot see. Large volumetric attacks are absorbed by the cloud network in front of it rather than by the WAF itself.
Is a WAF required for compliance?
PCI DSS requires either a WAF or a documented code review for public facing web applications. Most organizations choose the WAF because it is cheaper and repeatable.
Does a WAF slow the site down?
It adds a few milliseconds of inspection. Cloud based WAFs usually cache and serve from an edge network, so most web applications end up faster overall rather than slower.
Will a WAF stop somebody reading another customer's data by changing an ID?
No. That web request is perfectly well formed and no security policy matches it. Business logic flaws are invisible to a WAF and have to be fixed in the application.
What is virtual patching?
Writing a WAF policy that blocks the exploit for a known vulnerability while the real patch is scheduled. It protects the application temporarily, and it is temporary by definition.
Does a WAF cover the OWASP Top 10?
Partly. WAF rules block many injection and cross site scripting attempts from the OWASP Top 10. A WAF cannot fix broken access control or insecure design, because those are flaws in the application's own logic. It is layer 7 protection that buys time for the code to be fixed.
What are WAF rules?
WAF rules are the patterns and conditions a web application firewall checks each HTTP request against. Managed rule sets, such as the OWASP Core Rule Set, cover known attack techniques. Custom rules handle your own application, for example rate limiting a login page or blocking a country.
Keep readingRelated concepts
Read next · Network security What Is a Firewall? The network firewall this sits behind, and the question it answers instead. Open this next14 min- Network security · 12 min IDS vs IPS Both inspect content inline. An IPS looks at all traffic, a WAF understands one protocol deeply.
- Ports · 12 min What Is a Port Number? A network firewall works on port numbers, which is exactly why it cannot see inside port 443.
- Ports · 10 min Port 80 and 443, and Why You Still Cannot Close 80 What sits in front of the port once you need to look at what it carries.
- Network security · 10 min DoS vs DDoS, and What a Small Business Can Actually Do About Either Denial of service attacks explained, and which parts a small business can and cannot stop itself.
- Network security · 11 min What a CWPP Is, What It Protects, and What It Costs The layer on the workload behind the WAF, watching what runs once a request gets through.
- Infrastructure · 10 min Proxy vs Reverse Proxy, and Which One Your Business Runs Into Reverse proxies explained, and why most application firewalls are one with a security specialty.