Quick definition
A web application firewall (WAF) inspects requests sent to a website or web application and blocks those that match known attack patterns, such as SQL injection or cross-site scripting, before they reach the application. It adds a layer of protection but does not replace secure code.
A traditional network firewall decides which connections are allowed, mostly by address, port and protocol. That is essential, but a public website has to accept web connections from everyone, so a network firewall cannot tell an ordinary visitor from an attacker using the same entrance.
A web application firewall looks inside the web traffic itself. OWASP describes a WAF as applying "a set of rules to an HTTP conversation," with rules that cover common attacks such as cross-site scripting and SQL injection. It examines things like the requested address, form fields, headers and cookies, then blocks, logs or challenges requests that look malicious.
Where a WAF sits
A WAF sits in front of the application, often acting as a reverse proxy. OWASP notes that while proxies generally protect clients, WAFs protect servers. Common deployments include:
- a cloud service in front of the website, often combined with a content delivery network;
- a module running on the web server itself;
- a dedicated appliance in a data center.
What a WAF does well
- Blocks common, automated attacks that probe websites for well-known weaknesses.
- Buys time when a flaw is found. A rule can block attempts to exploit a known vulnerability while the code is being fixed. OWASP calls this virtual patching.
- Helps limit abusive traffic, such as floods of login attempts, when combined with rate limiting and bot protection.
- Provides visibility through logs of what was blocked and why.
Limitations
A WAF reduces risk; it does not remove vulnerabilities. OWASP is explicit that virtual patching blocks the exploit path without fixing the underlying code, so the real fix still has to follow. Rules can also block legitimate visitors (false positives) or miss attacks they were not written for (false negatives), so a WAF needs tuning and monitoring. It offers little protection against stolen passwords, flaws in business logic, or systems it does not sit in front of.
A practical example
A small online store runs on a popular e-commerce platform. A security advisory announces a flaw in a plugin the store relies on, but the store's developer needs a few days to test the plugin update against the store's customizations.
The store's WAF provider publishes a rule that blocks requests matching the vulnerability, and the store enables it. The site stays protected against that attack pattern while the developer finishes testing and applies the update. Once the update is live, the rule is no longer the only thing standing between the store and the flaw.
Why it matters
Automated tools continually scan the internet for vulnerable websites, so a business does not have to be well known to be targeted. A WAF adds a layer that can stop many of those attempts before they reach your application, and its logs show what is being tried against your site. For sites that take payments or store customer data, that layer can also support broader security and compliance programs.
Common mistakes
- Treating the WAF as a substitute for updates. Unpatched software is still vulnerable; the WAF only filters patterns it has rules for.
- Leaving it in monitoring mode indefinitely. Log-only mode is useful during setup, but it blocks nothing.
- Never tuning the rules. Overly strict rules break forms, checkouts or admin pages, and staff then switch protection off altogether.
- Leaving the origin server open. If a cloud WAF protects your domain but the server also accepts web traffic from anywhere, the WAF can be bypassed. Configure the server to accept web traffic only through the WAF.
- Ignoring the logs. Blocked requests show what is being attempted and can point to weaknesses worth fixing.
WAF vs. network firewall
| Network firewall | Web application firewall | |
|---|---|---|
| What it looks at | Connection details: source, destination, port and protocol | The content of web requests: addresses, form data, headers and cookies |
| Question it answers | Should this connection be allowed at all? | Does this web request look like an attack? |
| Protects | Servers and networks from unwanted connections | Websites and web applications from application-level attacks |
| Example rule | Allow web traffic; block outside access to the database port | Block requests whose form fields match SQL injection patterns |
The two cover different layers and are normally used together.
Frequently asked questions
Does a small business website need a WAF?
Many benefit from one, especially sites built on popular platforms and plugins, sites with logins, and sites that take payments. It is one layer of protection, alongside updates, strong authentication and backups, not a replacement for them.
Is a WAF the same as a CDN?
No. A content delivery network caches and serves content from locations closer to visitors. Many CDN providers also offer WAF features, which is why the two are often bought together.
Can a WAF block legitimate customers?
Yes, if a rule is too broad. That is why new rules should be tested and the logs reviewed, especially for checkout and form submissions.
Sources
- Web Application Firewall, OWASP (accessed November 9, 2026)
- Virtual Patching Cheat Sheet, OWASP Cheat Sheet Series (accessed November 9, 2026)