Web application firewall (WAF)

What is a web application firewall?

The term web application firewall (WAF) applies to security solutions that sanitize web requests and responses. WAFs function as a reverse proxy to the web server and try to detect attack attempts by monitoring all requests sent to the server (and potentially also checking server responses).

The primary functionality of a WAF is to filter out web attack attempts in real time, mitigating OWASP Top 10 application vulnerabilities such as SQL injections and cross-site scripting (XSS) as well as blocking other attack vectors. Due to the way they operate, WAFs can also have other use cases unrelated to security.

WAFs are both available as security services (SaaS) and as on-premises solutions for different operating systems.

How do web application firewalls work?

Web application firewalls work in a similar way to network firewalls but focus on a different layer of network traffic: the application layer. Network firewalls only analyze traffic in the lower layers. They rarely check the data that is sent in network packets but rather focus on the source and destination IP addresses and ports. On the other hand, web application firewalls look at the actual data sent in the headers and bodies of server requests and responses to decide whether this data is safe or not. WAFs should not be confused with intrusion prevention systems (IPS), which offer similar functionality but are not limited to the application layer.

If a web application or web service is protected by a web application firewall, the WAF can monitor all communication between the users and the web pages. For example, if a user logs in to the web application and sends their login and password, the WAF can examine the authentication data to verify that it does not contain any malicious code.

WAFs use pattern matching to recognize common attack attempts. They come with default rule sets, often updated regularly by the vendor, but also allow you to create or import rules of your own. In many cases, WAF rule updates can be automated as part of a more complex workflow – for example, a DAST scanner may automatically create such rules upon discovering vulnerabilities and send them to the WAF via its API for immediate mitigation.

If a WAF finds malicious code in the application payload sent by the user or received from a compromised web app, there are three actions it can take:

• Sanitization through filtering: If the WAF uses filtering, all requests containing malicious data are discarded. Depending on the configuration, the client may be notified using a return code or the request may be discarded silently.
• Sanitization through escaping: If escaping is used instead, potentially malicious content is automatically converted to make it harmless. For example, the WAF might apply URL encoding to convert < characters into %3C.
• Logging and alerting: Depending on the configuration, the WAF might only log potentially malicious requests for all or selected severity levels. This data is then analyzed separately to provide threat intelligence. Some WAFs also allow you to set alerts about suspicious traffic patterns, so you can, for example, get an email alert whenever a suspected organized attack is in progress.

Next-generation firewalls employ additional functionality. For example, some of them may use application profiling to better understand the structure of an application. Others experiment with machine learning to automatically create rules based on traffic data. However, this greatly increases the risk of false positives that cause the WAF to block legitimate requests. This can lead to lost business or broken application functionality, so any such features should be implemented and tested very carefully.

Advantages of web application firewalls

WAFs should be an integral part of a web application security program because they are the only tool able to immediately address two types of situations:

• Zero-day response: If a zero-day vulnerability is reported in the threat landscape, i.e. an exploitable weakness with no patch available, a WAF is the only means of protecting your web application while you wait for a patch or remediate the vulnerability manually.
• Temporary mitigation: If common vulnerabilities are found but your web application developer teams don’t have the resources to fix them immediately, you can use a WAF to temporarily mitigate these vulnerabilities until you are able to address the root cause.

Because of the way they are deployed, web application firewalls are also very useful for DDoS protection. Their unique position as a reverse proxy behind an SSL gate allows them to look for DDoS attack patterns in incoming HTTP requests and provide functionality such as request throttling, rate limiting, and more. They can also act as load balancers to optimize web server usage.

Disadvantages of web application firewalls

You should never rely on WAFs as the only means of keeping your web applications secure because this can only stop specific attacks while leaving the underlying vulnerabilities unfixed. There are also other reasons why WAFs should always be used in combination with other types of security tools:

• If you keep adding more WAF rules instead of reporting and fixing vulnerabilities, your developers might have no idea that they are producing insecure code, so you will keep getting more of the same vulnerabilities. This works against developer security education and against the recommended practice of making security everyone’s responsibility.
• The rules used by WAFs to detect attacks against specific vulnerabilities are not 100% foolproof. Because a WAF only blocks known attack methods, more advanced attackers can find ways to bypass WAF filtering and exploit the vulnerabilities anyway.
• If for any reason your WAF fails or operates incorrectly, your entire web environment will be wide open to attacks. If you were using the WAF to mask severe vulnerabilities instead of fixing them, you run the risk of exposing sensitive data or even invalidating your security certifications such as PCI DSS.
• WAF rules may cause false positives, leading the WAF to permanently block legitimate traffic. This can have serious consequences, from performance issues to a loss of reputation or business.
• When comparing traffic against very large rule sets, WAFs can cause minor latency issues, so it is best practice to limit the workload for the WAF by limiting rules to the absolute minimum required.

How to use a web application firewall

If you are working with a cloud provider such as AWS or Azure, you most likely already have a web application firewall available. There are also open-source web application firewalls such as ModSecurity, available for all popular web servers such as Apache, nginx, and Microsoft IIS. When enabled, these standard installations already have default security policies in place to block or sanitize most malicious traffic. Since these configurations are optimized for the public cloud and are unlikely to cause false positives or latency issues, you can leave them on as the first line of defense. However, to get maximum benefits from a WAF, you will likely need a more advanced WAF solution that is able to work together with a DAST scanner.

The recommended setup is to have an application security testing solution as part of your DevOps automation working in unison with a WAF in staging and production environments. The application security testing tool should have the ability to automatically export discovered vulnerabilities as WAF rules that can then immediately be imported into your specific WAF product. That way, you can be sure that any vulnerability discovered early on in the SDLC will be mitigated in production, even if the developer does not fix it.

Frequently asked questions

Written by: Tomasz Andrzej Nidecki, reviewed by: Zbigniew Banach