What Is a Web Application Firewall?
Web Application Firewalls (WAFs) are software that monitor and filter traffic to a website with the goal of stopping anything harmful.
WAFs look at web traffic before it gets to the website’s server, monitoring for potential vulnerability exploits. It’s like a security checkpoint for HTTP/HTTPS requests. They generally operate as a reverse proxy, receiving all the traffic for the website and only forwarding it on if deemed appropriate.
WAFs sit behind general purpose network firewalls. Compared to general purpose firewalls, WAFs put a tight focus on HTTP/HTTPS traffic. This allows them to provide more thorough security coverage at that level, but leaves them blind to all other security concerns. WAFs are a supplement for general purpose firewalls, not a replacement.
In some ways, WAFs are “smarter” than general purpose firewalls, as they understand the content of requests, not just the source and destination. WAFs sit in front of any security plugins that run inside your application, blocking requests before they get to the web server for processing.
The PCI Security Standards Council offers a robust definition of a WAF:
A web application firewall is a security policy enforcement point positioned between a web application and the client endpoint. This functionality can be implemented in software or hardware, running in an appliance device, or in a typical server running a common operating system. It may be a stand-alone device or integrated into other network components.
How Does a Web Application Firewall Work?
When a web browser communicates with a web server, the traffic takes the form of requests and replies. For example, the web browser will send a request to load the contents of a page for viewing. The web server will process the request and send a reply containing the content of that page.
The WAF examines those requests before the web server processes them and may generate a reply. Rules, sometimes called policies, are configured to determine which requests to allow through and which to flag as problematic. Flagged traffic may be dropped outright, or in some cases challenged with a CAPTCHA.
The WAF policies specify actions to take, like filtering out bots or blocking repeated login attempts. Actions can be either active, meaning they block flagged traffic completely, or passive, meaning they simply log questionable traffic while still sending it through. The rules can sometimes be modified to be very specific to a website’s needs.
WAFs typically operate using a blocklist, with rules identifying the patterns for common attack vectors. For example, a specific pattern might be used to identify a cross-site scripting (XSS) attempt. When the WAF finds suspicious traffic matching any of these patterns, it drops the traffic. Optionally, it might add the source to a blocklist and stop, or log, subsequent traffic from that source. This is also known as a negative security model approach.
Some WAFs use an allow list approach instead. This focuses on identifying traffic which matches expectations and rules out any outliers. This is a positive security model approach. An allow list approach tends to be far more restrictive, and is most commonly used in cases where access to some or all of the site needs to be highly controlled. Examples of this are blocking all traffic outside a predefined IP range (for example on an intranet), or blocking all traffic to the admin portion of a website.
Some WAFs take a hybrid approach by using allow lists, but adding in a secondary layer of blocklist checking for the most common types of attacks.
A web application firewall is only one piece of the total security picture. Like a security guard focused on a single door, they don’t pay attention to anything else. They are often paired with more general-purpose network firewalls. Similar solutions also exist for other protocols such as DNS.
Where Do WAFs Fit In?
According to the OSI Model — a conceptual model which describes computer communication — the application layer represents the information your browser sends to a web server when you click a link, and the response it receives. This is where the “application” in web application firewall comes from.
The application layer defines protocols and APIs for end-user needs. Examples are the HTTP/HTTPS standards used by web browsers and web servers, and the SMTP, IPOP, and POP3 standards used by email clients and servers.
An application firewall works against a specific protocol and is able to focus on its needs. A virus scanner running on an email server and discarding email with suspicious attachments is an example of an application firewall.
A web application firewall is a firewall specific to HTTP/HTTPS traffic, focused directly on web application security.
This definition is a vital starting point, but it can also be a bit misleading. The vast majority of WAFs on the market go well beyond the scope of the OSI application layer to provide additional levels of security.
In fact, the HTTP/HTTPS protocol itself defies the OSI model with a few features which technically belong in layer 6, such as containing information about encoding.
There is no clear-cut feature list for a WAF, and the amount of security they offer can vary greatly depending on the level and the specifics of the solution.
Building and maintaining a list of filtering rules for a WAF is no small task. Fortunately, the OWASP ModSecurity Core Rule Set, provided by the Open Web Application Security Project, provides a thorough and well vetted starting point.
This set of rules can block common malicious traffic to your web app. OWASP is a well trusted resource on web security education and best practices, so the majority of WAF solutions on the market use these rules as a starting point.
What WAFs Do Exactly
WAFs monitor and filter HTTP and HTTPS traffic, examining it and deciding whether to allow the traffic through. They can also log information about traffic, providing powerful data for mitigation efforts in the cases where an attack does get through. This complements a more general firewall solution, and addresses application specific details which are out of the scope of other types of firewalls.
So what types of malicious traffic can they stop? What, exactly, can WAFs do for you?
Detect Common Exploits and Injection Attacks
WAFs offer excellent protection against injection attacks, as described in the OWASP Top 10 2021 list of most common vulnerabilities. OWASP maintains an annual list of the Top 10 most common vulnerabilities to help advise and guide on security policies and security solutions. While injection attacks have recently fallen down the list slightly, they’re still very near the top and a major concern for your web application security.
Detect Server Side Request Forgery
WAFs can also help protect from server-side request forgery, another item from the OWASP Top 10 2021. Server-side request forgery is a class of attack which sees the application tricked into sending information to unintended locations, and can reveal sensitive information about the server or about customer’s accounts.
Detect DDoS and/or Web Scraping Based Attacks
By examining the contents, volume, and patterns of traffic, WAFs can identify patterns from specific IP addresses or IP address groups which suggest DDoS or scraping. In some cases, this is complemented with checking a global blocklist for concerns about the source of the request.
What WAFs Don’t Do
WAFs bring a lot to the table, and most solutions on the market already step outside the traditional WAF role to bring in additional protections. However, even these are still only part of a full security solution. There are some problems WAFs just don’t solve.
WAFs Don’t Protect Your Whole Network
Thinking back to the OSI model, we know that WAFs operate at the application level and focus solely on HTTP/HTTPS traffic. WAF protection is very specific and scoped. A textbook WAF does nothing to protect other applications on your network, or contribute towards network security as a whole. Because of this, many WAF solutions come paired with additional protections. Cloudflare is a great example, as its WAF comes paired with DDoS protection. Furthermore, many WAFs also provide functionality historically provided by intrusion prevention systems, and even malware detection.
For those seeking more robust protection, I would suggest turning your attention towards general purpose firewall solutions which feature a WAF as one of many features.
WAFs Don’t Understand Full Context
WAFs don’t understand the context about specific pages or endpoints within the web application. In the eyes of a WAF, the submission of a login form and of a search form are no different, despite the login form’s proximity to highly sensitive data. In both cases, the WAF only sees traffic to the website with posted form data it can scan for patterns.
WAFs Don’t Understand Business Rules
WAFs aren’t aware of the meaning of the data or the business rules around them. For example, a WAF cannot protect you from a Mass Assignment Vulnerability Exploit. The knowledge around which data should and should not be defined by the end user is business knowledge which lives in the codebase.
WAFs Provide False Negatives and Positives
WAFs operate via pattern matching. There will be false positives. Traffic that should have been let through will be blocked. There will also be false negatives, and malicious requests will be let through.
WAFs Don’t Offer Protection From All OWASP Top 10 Issues
While WAFs are a definitive solution for cross-site scripting, SQL injection, and other injection based application vulnerabilities, some entries on the OWASP Top 10 list are outside of a WAF’s reach.
In fact, web application firewalls may create opportunities to introduce new vulnerabilities from the OWASP Top 10 list. For example, network-level WAFs require strong attention to detail to avoid security misconfiguration, an entry on the OWASP Top 10. There’s potential for a poorly secured network-level WAF to serve as a means of accessing the application’s internal network.
Levels of WAFs
WAFS can be grouped into four distinct levels:
- Cloud Level
- Network Level
- Server Level
- Application Level
The level indicates where the WAF is placed, as shown in the diagram below:
Options vary greatly in scope of coverage, pricing, ease of use, and integration with existing tools. Let’s look at each level in detail.
Cloud-Level WAFs
Cloud-level WAFs are third-party SaaS products that live in the cloud and provide WAF functionality. Traffic is routed through the third-party product where it is inspected and filtered as required. Traffic deemed safe moves forward to the web server.
Examples
Pros of Cloud-Level WAFs
- Filter out DDoS attack traffic before it gets to the server
- Cloud-level WAFs can typically be set up in under an hour using a guided web interface.
- They tend to have robust documentation, often with customer support ready to help.
- Cloud-level WAFs provide coverage for multiple websites and track IP reputation across sites. Learning an IP address is a bad actor because of an attack on one site allows them to protect all customers from that source.
- Cloud-level WAFs tend to be well architected and run on reliable infrastructure, making them ready to scale up as demand increases.
- Most charge a fairly low monthly fee, sometimes with a free tier.
- They usually adapt quickly to new threats. Cloud-level WAF customers quickly gained protection from Log4j exploits when the vulnerabilities became widespread knowledge in late 2021.
Cons of Cloud-Level WAFs
- A cloud-level WAF will typically add a line item to your monthly expenses.
- Cloud-level WAFs are managed by a third-party. Decisions on their end are out of your control.
- Their popularity can make them a target and lead to increased attacks against the provider itself, which could impact you through service disruptions.
- When they are down, you’re down. There is little you can do in this situation other than wait or quickly migrate away from their service.
Network-Level WAFs
Network-level WAFs are physical hardware appliances pre-loaded with dedicated WAF software. They are deployed on a network to provide protection to applications hosted on that network. Network-level WAFs provide a built-in user interface to configure, monitor, and otherwise manage WAF functionality. Many commercially available firewall products feature a WAF component, placing them in this category.
Network-level WAFs can provide dedicated hardware attached near to the web server. This shifts the processing needs off of the web server until the request has been verified while having the most direct network connection possible between the two.
Examples
- Barracuda Web Application Firewall
- Fortinet
- Citrix ADC WAF 14020
- Sophos Firewall, a complete firewall featuring WAF functionality
Pros of Network-Level WAFs
- Network-level WAFs may answer a number of needs for organizations seeking compliance with specific security guidelines such as HIPPA, PCI DSS, or NIST 800-53. Moving web application firewall functionality on-premise allows the organization to fully control the environment and access to it.
- For operations with multiple projects needing highly custom WAF coverage, network-level WAFs provide a single, on-site interface for defining and managing rules and settings.
- All WAFs have the potential to impact page load times, as they introduce processing between the user’s request and the response, increasing latency. The performance impact varies greatly depending on configuration and setup, but network-level WAFs are least likely to introduce performance issues, as the networking is a direct link and the processing has dedicated hardware specifically designed for the task.
Cons of Network-Level WAFs
- Network-level WAFs have an upfront expense, as you must buy the physical appliance. In addition, staff time is needed to get the appliance installed and configured, and to update the network and web server to work with it.
- Despite owning the physical server, you may still have a monthly fee attached to cover software updates and patches. Further, monitoring and managing the appliance will consume staff time.
- Network-level WAFs use dedicated hardware, which comes with the risk of hardware failure.
- The biggest downside of WAFs at the network level may be that you have to install hardware. This means you can only use them if you have access to your datacenter using co-located equipment or if you lease a physical server. You can’t use this approach with shared or cloud hosting.
Server-Level WAFs
Server-level WAFs add WAF functionality directly to web server software. They generally come in the form of plugins or modules added to the web server software already in use.
The popular ModSecurity package is a well-known example of a server-level WAF. ModSecurity is a long-standing and respected open source project which can integrate with Nginx, Apache, or IIS servers. It is quick and easy to set up, with a rich history of documentation and discussion available around the web. Unfortunately, official support for ModSecurity is scheduled to be sunset in July of 2024. The project has been turned back over to the open source community, making its future unclear.
Examples
Pros of Server-Level WAFs
- Server-level WAFs add functionality directly to the web server software. No other alterations need to be made to the DNS or other infrastructure.
- There’s typically no monetary cost attached at this level.
- Multiple projects that are sharing web infrastructure will benefit from shared protection.
Cons of Server-Level WAFs
- WAFs at server level generally operate in isolation, and are unable to compare notes with other WAFs about specific IP addresses to gain a sense of their reputation.
- Compared to WAFs operating at the cloud level, server-level WAFs typically require a notable amount of installation and configuration.
- Server-level WAFs contribute to overall server load, as they operate directly in the web server software.
- A WAF at the server level complicates web server configuration. This may come into play if the infrastructure needs to migrate or expand operations. For example, you may need to synchronize configuration files regularly if using load balancing.
Application-Level WAFs
Application-level WAFs integrate directly with the codebase of the project needing protection. In the case of WordPress, application-level WAFs are typically plugins. They sometimes provide the same benefits as a cloud-level WAF by integrating via an API for real-time communication with a cloud-level solution.
Examples
Pros of Application-Level WAFs
- Application-level WAFs are usually easy to install using familiar management tools, such as WordPress plugins or Composer.
- They offer integrated monitoring and management, as the solution is integrated into the software directly.
- WAFs at the application level are written with some knowledge of the environment they will operate in. For example, an application-level WAF targeting WordPress can be written using WordPress best practices and knowledge of how requests flow through the codebase.
Cons of Application-Level WAFs
- Since an application-level WAF operates as part of the web application itself, some aspects of protection are not offered. For example, they are ineffective against a DDoS attack when compared to a cloud-level WAF, which prevents the traffic from ever reaching the web application at all.
- Subscriptions are required for some, but not all, application-level WAFs as they integrate with cloud based services.
Why Doesn’t SpinupWP Install a WAF?
Here are a few of the things we do to help keep your websites secure:
- Up to date software.
- SpinupWP installs the UFW firewall package, and configures it to lock down any ports which aren’t in use.
- On the WordPress side, we install Limit Login Attempts to help block brute force attacks.
- SpinupWP installs and configures Fail2ban out of the box, which monitors log files to analyze traffic to the server and blocks traffic from a source if a request is repeated too many times.
- SpinupWP configures Nginx to defend against XSS, clickjacking, MIME sniffing, and other attacks from day one.
- SpinupWP offers tools to easily create and update SSL certificates, and keep your site secure over HTTPS.
Taken together, these steps offer powerful protection.
Sometimes WAFs cause more problems than they prevent. For many websites, simple steps can mitigate a majority of problems, and the tradeoffs may not be not worthwhile. For example, a WAF may filter out legitimate traffic.
However, there may be reasons why you might want to extend the security on your site with a WAF.
When and Why You Might Want to Use a WAF
There are many factors to consider when deciding how to approach the security on your site. In certain situations, a WAF can improve security and reduce the chance of your site being exploited. To capture that value, you will need to make an investment of time and likely money.
There are a huge number of factors to consider when deciding whether a WAF is a good fit for you, including:
- The site and its content
- Amount of traffic
- If it is controversial, political, or likely to attract negative attention for any reason
- If the site houses any sensitive or customer data
The risks are fairly minimal for a simple informational website.. A complex ecommerce site, on the other hand, requires more careful consideration as sensitive customer information may be at risk.
Ultimately, only you can make the judgment call on whether or not a WAF will provide improved peace of mind, and whether it’s worth the investment.
Setting up Cloudflare is a fantastic first step if you want to dive in. This can easily get you protection from DDoS attacks, cross-site scripting, SQL injection, and many other injection-based attacks.
For a truly deep-dive evaluation of your infrastructure needs and what WAF might be right for you, check out the OWASP Web Application Firewall Evaluation Criteria Project.
Wrapping Up
Implementing a web application firewall, like adding a load balancer or setting up incremental backups, is a step that needs careful consideration. You need to decide if a WAF is really needed, and if so, what type makes sense for your infrastructure.
For the majority of WordPress websites, following good security procedures and keeping tight control of the server stack is usually a better approach and means a WAF is probably more trouble than it’s worth. On the other hand, if you’re not able to tightly control your servers and sites, or are building websites or web applications that are handling very sensitive information, or are at a higher risk of possible attack (like internet banking or online government portals) implementing the right WAF should be considered vital.
Do you have any web application firewalls installed on your sites? Perhaps you want to try one of them out? Let us know in the comments.
