top of page

Cloud WAFs vs. Self-Hosted WAFs: How Do You Choose?

A web application firewall (WAF) is an essential piece of software that protects your web application or API from application layer attacks (or layer 7 of the OSI model).


Basically, a WAF sits between the user making a connection request to your website and your web server. The WAF analyzes the request payload for suspicious patterns that might indicate whether a connection is malicious or not. Once the WAF has made a decision, it will either drop the connection or forward it through to your web server.




With modern websites essentially requiring a WAF so as not to be exploited, the WAF industry has seen significant growth in recent years. Consumers or businesses looking for a WAF solution have a lot of options.


This article will explore some of the options available but with a specific focus on helping you choose between a cloud-hosted WAF and a self-hosted one.


Cloud-Hosted WAF

A cloud-hosted WAF is usually available as a software-as-a-service (SaaS) offering, where a service provider offers their WAF software as an external solution for your web application.


Connection requests to your website are first routed to the WAF in the cloud, usually via a domain name system (DNS) configuration. Requests are analyzed for malicious payloads or signatures, and once a verdict has been made, the request is either dropped or forwarded to your web application.


Some popular cloud-hosted WAFs include CloudFlare WAF, Imperva Incapsula WAF and Amazon Web Services (AWS) WAF.


Self-Hosted WAF

A self-hosted WAF is generally deployed as an integral part of your web application's deployment process.


In general, it works the same way as a cloud-hosted WAF. All connection requests are first routed to the WAF software and analyzed to see if the connection is good or bad. If it's bad, it gets dropped. If it's nice, it gets to work with your web application.

ModSecurity and open-appsec are examples of self-hosted WAFs.


The Difference Between Self-Hosted and Cloud-Hosted WAFs

While, in essence, the two different types of WAFs do the same job (analyzing connections and deciding whether it needs to be dropped or not), they are fundamentally different in three major ways: deployment, configuration, and pricing.

This article will explore these differences to help you make a choice for your next (or current) web application firewall.


Cloud WAFs vs. Self-Hosted WAFs

There are a few comparisons you can explore for self-hosted and cloud-hosted WAFs. The focus of this article will be comparing options that will help you determine which solution to choose.


Ease of Deployment

A WAF needs to be easy to install or deploy. It's hard to deny this, but a cloud-based WAF really is the easier one to deploy to your application. For example, it can be as easy as doing the following:

  • Setting up your website's DNS entries to route traffic to the provider

  • Configuring your application on the provider's frontend

  • Tuning a few security settings

And that's it. You're good to go.


If you host your web applications on AWS, the AWS WAF integrates fairly easily. You just configure it to inspect the traffic of one or more of your AWS-hosted applications, and it should work.


A self-hosted WAF's deployment might be more involved, but that doesn't mean it's worse. It just means you have more options for deployment. It will allow you to protect different types of environment - such as private clouds and also protect applications traffic within your data center as opposed to only traffic from the Internet.


open-appsec, is a modern open-source machine-learning based WAF that has multiple capabilities:

  • Deploy as part of a Kubernetes cluster using Helm charts

  • Install as an add-on for Nginx or Kong

  • Make open-appsec part of your continuous integration, continuous deployment (CI/CD) pipeline, and install and configure it declaratively as code

  • Decide whether you want to install the WAF component in stand-alone mode or connect it to a SaaS frontend with an agent


Pricing

Pricing is most likely what project managers and/or architects are most interested in. It's important to look at costs as well as your web application and your daily visitor count, as it could be one of the bigger factors you need to compare when looking for a new WAF solution.


Cloud-hosted options are usually priced as some sort of pay-as-you-go pricing option.

With AWS WAF, your billing is determined by the number of web access control lists (ACLs) that you create, the number of rules you create in each of those ACLs, and the number of requests made to your application. The problem with this approach is that it's hard to budget for, especially for a new web application that doesn't yet have established traffic patterns.


Keep in mind that this pricing excludes other AWS components, like the Application Load Balancer.


The free version of open-appsec also includes one of its strongest features: a machine learning (ML)–powered WAF engine that can stop attacks preemptively.


The other pricing tiers also offer some advanced security features as well as some flexibility in terms of payment: a pay-as-you-go and an annual payment option are both available.


Scaling

You should be able to add more resources as the load to your application increases. In the same way that you might add a few more servers to handle the extra traffic from a Black Friday special on your site, your WAF solution should be able to scale as well.

Some individuals may not see scaling as an important factor when deciding on a new WAF, and in most cases, they're probably right. With cloud-based WAF vendors, they should handle the scaling for you, and you don't need to worry about whether their service will scale automatically as traffic to your web application increases.

However, this could also be considered one of the downsides.


What if the vendor can't keep up? What if the vendor misconfigured something? What if they're dealing with an outage? The same sense of peace you had when the service was working can now turn into a sense of fear. When anything happens to a vendor's service, you're either losing traffic or traffic is no longer being protected by a WAF. The worst part is you can't do much about it except wait and hope the vendor resolves it quickly.


In a self-hosted scenario, while it might be more finicky to get your scaling right, at least you own the entire process and you're in a position where you can make decisions.

And if things go pear-shaped and your web application breaks down, you have full visibility over any log entries, warnings, or error messages that will put you on the right path to resolving the issue.


If you've got the scaling for your web application configured correctly, you shouldn't need to worry about the scaling for your WAF. As you scale your application, the WAF, being part of the application pipeline, will scale right along with it.


Advanced Security Features

Yes, both types of WAFs do the basics: check to see if a connection is malicious or not and drop it accordingly. At the very least, your WAF should cover the basics, like the OWASP Top Ten application security risks.


But what about advanced security features? Bot detection? IPS signatures? Preemptive threat mitigation? The chief information security officer (CISO) in your team will be very interested in this comparison point.


As alluded to before, a lot of cloud-based WAF providers lock some of the more advanced security features behind higher-priced tiers.


AWS does offer some free rule sets, but you can pay extra for managed rule groups made available by other security vendors on the AWS Marketplace.


open-appsec ML-based detection engine utilizes two ML models for high accuracy with a low false positive rate. The first model is used to compare your connection against millions of benign and malicious connections to determine whether it fits a known attack or attack pattern.


The second model is trained using the context of your application: the model learns what the standard behavior for your application is based on normal user interaction. Should the first model not be able to classify the connection request with a high level of confidence, the second model is employed. If the connection looks like it fits within the scope of your application's day-to-day operations, the connection is allowed.


As with the other WAF providers, some more advanced features are behind higher pricing tiers, but the ML-powered WAF is available on the free tier, which is good news for any CISO looking to switch their WAF solution.


Conclusion

As you can see, there are many factors you need to consider when selecting a new WAF for your new or existing web application or API. Hopefully, this article will help you make the right decision for your company.

Comments


Experiment with open-appsec for Linux, Kubernetes or Kong using a free virtual lab

bottom of page