What a Web Application Firewall Does, and What It Doesn't

A web application firewall (WAF) inspects HTTP and HTTPS traffic between users and a web application, and blocks requests that look like attacks. It's a valuable layer of protection, but it's often misunderstood. Knowing what it can and can't do helps you use it well.

How a WAF works

Traditional network firewalls mostly decide based on addresses and ports. A WAF works at the application layer: it reads the actual HTTP request, including the URL, headers, cookies, parameters and body, and evaluates it against a policy.

To inspect HTTPS traffic, the WAF needs to see the decrypted request. That's why WAFs are usually deployed where TLS is terminated, such as on a load balancer or reverse proxy in front of the application.

WAF policies typically combine two approaches:

• Negative security model. Block requests that match known attack patterns, usually through attack signatures. Easy to start with, but it only catches what the signatures describe.
• Positive security model. Allow only what the application is known to accept, such as specific URLs, parameters, value types and file types. Stronger, but it needs to be kept up to date as the application changes.

What a WAF helps with

A well-tuned WAF can help protect against many common web attack classes, including:

• Injection attacks such as SQL injection and command injection
• Cross-site scripting (XSS)
• Path traversal and attempts to access files outside the web root
• Malformed or non-compliant HTTP requests
• Brute-force login attempts and some forms of automated bot traffic, where these features are configured
• Some application-layer denial-of-service patterns, where these features are configured

It can also buy time when a new vulnerability is disclosed, by blocking known exploit patterns while the application is patched.

What a WAF doesn't do

• It doesn't fix vulnerable code. If the application has a flaw, the WAF may block some ways of exploiting it, but attackers can find others. The code still needs fixing.
• It can't understand your business logic. A request to view another customer's order may look perfectly normal to a WAF. Authorisation flaws need to be addressed in the application.
• It doesn't replace patching. Servers, frameworks and libraries still need updates.
• It isn't a complete DDoS solution. Large network-level floods need to be handled upstream, before they reach your infrastructure.
• It isn't "set and forget". Policies need tuning to avoid blocking legitimate users, and review as the application changes.

Defence in depth

A WAF works best as one layer among several: secure development practices, regular patching, strong authentication, sensible network segmentation, monitoring and a plan for responding to incidents. Each layer covers gaps in the others.

Questions worth asking about your WAF

• Is it actually blocking, or only monitoring?
• When was the policy last reviewed against the current application?
• Who investigates when a legitimate user is blocked, and how quickly?
• Are its logs going somewhere your team actually looks?

If you're unsure of the answers, that's a good place to start.