Web Application Firewall (WAF)

A Web Application Firewall (WAF) is a piece of software that you can use to inspect HTTP traffic and address security concerns. A traditional firewall restricts access at a network level, so you might say, visitors can connect to my website using HTTP (port 80) and HTTPS (port 443) but that's it. The issues is that, as web applications have become more complicated and with more access to sensitive data and backend systems and databases, giving access to "just web traffic", is actually quite a wide definition. It's like bolting all your windows for security reasons, and then leaving your front door side open.

A WAF implements a doorman for your web server. It checks every request coming in and looks for illicit or unwanted activity and blocks those requests. How it does this depends on each WAF. Most have a list of rules or signatures for common attacks, some monitor your application for a while and use that experience to highlight unusual requests, some have commercial support where an updated policy is available for any new attack signatures as they become known. However, like some doormen, they can become a little over zealous and block legitimate web traffic. So you do need to spend a good amount of time setting a WAF up, monitoring it, and tweaking your rules to ensure you don't block real visitors.

This depends on the WAF you implement, but typically they run in one of two ways:

1. A WAF may run as a separate piece of infrastructure in front of your web server (for example on a load balancer, or as a reverse proxy) and inspect traffic before it hits your web server.
2. An embedded WAF is part of your web server and those can be configured in your web server configuration. ModSecurity is a well known opensource WAF that originally started as an Apache module but is now available for other web servers like nginx and IIS too.

There are small advantages and disadvantages to each method of running, but the differences are minor.

Once the WAF is installed (refer to the documentation for the particular WAF) it will likely need configuring with rules or signatures to scan for. These rules may be supplied by the application vendor, by third party vendors (who will most likely charge for them) or may be written by yourself. ModSecurity, for example, has an open source OWASP Core Rule Set (CRS) for ModSecurity which is available for free and includes protection against many common attacks.

At it's very simplest a WAF can look at requests and filter out "bad" traffic, for example based on the User Agent supplied (allow "Chrome", block "HackerTool"). More complex rules can be built up but this is the basic principal. WAFs can also give you you a view on what hits your website every day. Yes you will have your web server logs, but a WAF typically can log more information about the request, and you'll be surprised at the amount of bad traffic your website receives (and every website receives!) after you turn on a WAF. Most of these bad requests are probably harmless and have been happening for a while but it's a real eye opener when you first see the amount of alerts.

Most WAFs offer a "Detection Only" mode, where they can report on any traffic that breaks the rules, but not actually block. This is very useful for when you first set up the WAF to make sure it is configured correctly. It is recommended to run in this mode until you receive no false alerts and how that takes will differ from site to site but a period of a few months is not uncommon.

A WAF works at the server level, and so no support is required from the web browser level. Most WAFs can work separately to the web server (though some work in an embedded mode so therefore can only work in that mode for the web servers they support).

Support for the WAF itself may be provided by the company - at a cost. There are some open source WAFs that are supported by a community of other users volunteers, typically on mailing lists and support can vary depending on the WAF.

The main downside is the risk of "false positives" where you block legitimate traffic because it looks like bad traffic. Added security is great and always should be looked at, but if that comes at the cost of losing visitors or online sales, then it will quickly be turned off. Rules and signatures can be adjusted and refined to stop real traffic being blocked but that requires time and effort, and if not done correctly, then you most likely won't get the opportunity to just ask any blocked visitors to try again.

Installing an monitoring a WAF is also a big commitment, so is not something that you should undertake lightly. It could take several months to set up, and will require only monitoring to ensure legitimate traffic is not being blocked. In larger companies a clear owner of the WAF will need to be established and procedures will need to be set up and followed regarding monitoring it, and making any necessary changes in response to that monitoring or known changes happening on the website.

A WAF, as it's name suggests, is primarily designed to protect web applications, rather than web servers. Most web servers server static requests have pretty good protections built in as the requests they handle are usually pretty basic. Applications are much more difficult to protect as they are variable by nature. A WAF can add protection for protocol violations, injection attacks (including SQL injection, XSS and others), DoS attacks, Brute Force attacks and others. If you run any sort of dynamic web application which is available over the internet then you should implement a WAF. If you just run a simple web server, then it may not be necessary (though on the flip side can often be easier to set up so what harm in setting up). They can provide protection, greater insight into your traffic, and even reduce unwanted traffic (e.g. bots wasting valuable resources).

As WAFs basically just run a set of rules, it is often easy to write a new rule which can provide what is known as virtual patching. Supposing you find a critical bug in your application and when a certain request comes in, it overrides your applications security and gives access to data that should not be available. Fixing this could take some time to develop, test and deploy. In the meantime you are running this risk. However if the exact request can be recognised by a WAF rule, then that is often easier to implement in the short term than an application release. This gives you protection quickly, without the risk of having to release software before it's fully tested. Obviously this should only be used as a short term fix, and the underlying application error should still be fix but virtual patching may give you the time to do that properly.

• OWASP Best Practices: Use of Web Application Firewalls
• ModSecurity a free WAF for most of the popular web browsers
• OWASP Core Rule Set (CRS) for ModSecurity

This page was originally created on 09-Aug-2015 and last edited on 28-Jun-2022.