What Is a Web Application Firewall and Do You Need One?

A web application firewall (WAF) is a filter that sits in front of a website or web app and checks each HTTP request against a set of rules before the app sees it. If a request looks like an attack, such as a SQL injection string or a cross-site scripting payload, the WAF blocks it. It is a useful layer of defence, but it does not fix the flaws in your code.

This guide explains what a web application firewall does, how it differs from a normal firewall, the main ways to deploy one, and where it falls short. It also covers whether you need one and how it fits alongside testing.

What does a web application firewall do?

OWASP describes a WAF as an application firewall for HTTP applications that “applies a set of rules to an HTTP conversation”. Those rules usually cover common attacks like cross-site scripting and SQL injection.

Think of it as a checkpoint on the road to your app. Every request passes through it. Clean requests go on to the app, but suspicious ones get stopped, logged, or challenged.

OWASP also notes that a WAF can be thought of as a reverse proxy. An ordinary proxy protects the people browsing. A WAF protects the server they are talking to.

How is a WAF different from a network firewall?

A traditional network firewall decides who can reach which port. It might allow web traffic on port 443 from anywhere and block everything else. It does not read what is inside that web traffic.

A WAF works one level up, so it reads the content of the request itself: the URL, the query string, the form fields and the headers. That is how it can spot a malicious string hidden inside a request that a network firewall would happily wave through.

You usually want both, because they solve different problems.

How does a WAF decide what to block?

Most WAFs use rules. Each rule describes something to look for and an action to take. AWS WAF, for example, lets you control access based on criteria such as the IP address a request comes from or the values in a query string. The protected service then answers with the content, an HTTP 403 (Forbidden) response, or a custom response.

Rules come from a few places:

• Ready-made rule sets. The OWASP Core Rule Set is a free set of generic attack detection rules for ModSecurity and compatible firewalls. It covers attacks such as SQL injection, cross-site scripting and local file inclusion.
• Vendor-managed rules. Commercial and cloud WAFs ship rules that the provider updates for you.
• Your own rules. You can block a country, rate-limit a login page, or protect an admin path.

The Core Rule Set project says it aims to protect applications with a minimum of false alerts. In practice, any rule set needs tuning. A rule that is too strict will block real customers. One that is too loose lets attacks through.

What are the main types of web application firewall?

OWASP says a WAF can be an appliance, a server plugin, or a filter. In day-to-day business use, you will meet three common set-ups.

Cloud or reverse-proxy WAF

Traffic goes through a provider’s network first. It is quick to switch on and needs no hardware. Cloud platforms offer this too: AWS WAF can protect resources such as a CloudFront distribution, an Application Load Balancer or an API Gateway REST API.

Host-based WAF

This runs on the web server itself, as a module or plugin. ModSecurity is a well-known example. You get fine control, but you also take on the upkeep.

Network appliance

A physical or virtual device sits in your data centre. This suits larger organisations with their own infrastructure and a team to run it.

What attacks can a WAF stop?

A well-tuned web application firewall is good at the noisy, well-known stuff. That includes SQL injection, cross-site scripting and automated probing for common weaknesses. It can also slow down bots by rate-limiting requests, and it gives you a log of what is hitting your site.

That log has real value, because when you can see the scanning, you can see what attackers are after.

What can a WAF not do?

This is where many businesses get caught out, since a WAF is a filter, not a repair. If your app has a flaw, the flaw is still there behind the filter.

OWASP is open about the cost of running one. Customising a WAF to an application can take substantial effort, and that work has to be maintained as the application changes. Add a new feature or change a form, and your rules may need updating too.

Rule-based filters also have blind spots:

• Logic flaws. If a user can change an order ID in the URL and see someone else’s invoice, the request looks perfectly normal. A rule has nothing to match.
• Broken access control. Again, the traffic is valid. The app simply fails to check who is asking.
• Evasion. Attackers can reshape a payload so the app still understands it while the filter misses it. Encoding tricks and odd formatting are common ways to do this.
• New attacks. A rule can only match what its authors already know about.

None of this makes a web application firewall a bad idea. It just means you should not treat it as proof that your app is safe.

Do you need a web application firewall?

For most UK businesses that run a public site, a customer portal or a web shop, a WAF is a sensible and fairly cheap layer. It matters more when:

• your app takes payments or personal data;
• you cannot patch quickly, for example with older software;
• you run a lot of third-party plugins, as many WordPress sites do;
• a contract, insurer or auditor asks for one.

If you handle card payments, check the current PCI DSS wording with your assessor, because it covers how public web apps must be protected.

Is a WAF a substitute for penetration testing?

No. They do different jobs. A WAF tries to block attacks as they arrive. A web app pen test looks for the weaknesses behind it, the way a real attacker would, and tells you what to fix.

The two work well together. For example, a tester can check whether your WAF rules actually stop what they should, and whether a skilled attacker can get round them. They will also find the logic and access control problems that no filter can see. If you want a view on how your site would hold up, Aardwolf Security can scope a test with you. You can get in touch to talk it through.

A pen test is also different from automated scanning. Our guide to penetration testing vs vulnerability scanning covers the gap. For the flaws that WAF rules most often target, see our explainers on cross-site scripting and the OWASP Top 10.

How do you choose and set up a WAF?

Start with the basics, then tune.

1. List what you are protecting. Public site, login pages, APIs and admin areas all behave differently.
2. Pick a deployment type that your team can actually run. A cloud WAF is often the easiest start for smaller firms.
3. Begin in monitor mode. AWS WAF, for instance, has a count action that records matches without blocking. Review what would have been blocked before you switch to blocking.
4. Tune the rules. Remove false positives, which are real users or tools being blocked by mistake.
5. Review logs regularly. A WAF that nobody watches is only half working.
6. Test it. Have someone check that the rules block what you think they block.

Web application firewall FAQs

Is a WAF the same as a normal firewall?

No. A network firewall controls which connections are allowed. A WAF reads the content of web requests and blocks the harmful ones.

Can a WAF be bypassed?

Yes. Rule-based filters can miss payloads that are reshaped to slip past the rules, which is why testing and secure code still matter.

Does a WAF slow my website down?

It adds a check to each request, so there is some overhead. Still, for most sites it is small. Cloud WAFs often come bundled with caching, which can offset it.

Will a WAF stop ransomware?

Not on its own. A WAF guards your web apps, while ransomware often arrives through phishing, stolen logins or exposed remote access, which a WAF does not cover.

Is a WAF enough to keep a web app secure?

No. Treat it as one layer. Fix the underlying flaws, keep software patched, and test the app regularly.