What Is a WAF? | Web Application Firewall Explained

A web application firewall (WAF) is a type of firewall that protects web applications and APIs by filtering, monitoring and blocking malicious web traffic and application-layer attacks — such as DDoS, SQL injection, cookie manipulation, cross-site scripting (XSS), cross-site forgery and file inclusion.

As a Layer 7 defense, WAFs focus on traffic between web applications and the internet. Their ability to detect and respond to malicious requests before web applications and web servers accept the requests provides businesses (and their customers) with essential security.

Emergence of WAF Technology

In the pre-cloud era, you could use firewalls to segment internal from external networks to protect your assets from malicious network traffic. But the traditional firewall approach isn’t ideal for the cloud. Many applications can't be isolated on internal networks because they need to connect to the internet.

Efforts to safeguard against the rise in attacks on web applications led to the development of WAF technology in the late 1990s. Early versions of web application firewalls protected applications from the submission of illegal characters. The WAF has since evolved to sit between the application and the client — a position referred to as “inline” — where it filters HTTP traffic to and from the web service to block the malicious request.

Figure 1: Legacy WAF deployment

Parallel with emergence of WAF technology, the OASIS Web Application Security Technical Committee’s (WAS TC) vulnerability work was expanded into the Open Web Application Security Project’s (OWASP) Top 10 List. Decades later, the OWASP Top 10 remains the industry standard for web application security compliance.

Together, these two developments — the WAF and the OWASP Top 10 — have given us a defense to help stop threat actors attempting to compromise our systems, consume our resources and exfiltrate our data.

Video: Understand the difference between network firewalls and web application firewalls (WAFs).

WAFs: A Critical Security Component

With attacks on web applications a leading cause of breaches, protecting applications and APIs has been — and is — a paramount concern for application security engineers, security architects and information security professionals. Because applications are often released with OWASP Top 10 vulnerabilities, web application security standards must be integrated into the software development lifecycle (SDLC).

Web application firewalls play a role protecting vulnerabilities from exploitation by providing a layer of security that can't be achieved with network firewalls. Conventional network firewalls simply aren’t equipped to protect web-facing applications that need to accept and respond to requests for web content from the internet.

WAFs solve the problem by providing a means of filtering network traffic while still allowing applications to connect directly to the internet. Instead of creating a wall between internal and external network resources, WAFs function like screens, letting friendly traffic through but blocking malicious traffic.

In this way, WAFs help to protect against some common web application security risks, such as improperly designed apps and injection attacks. Although WAFs don't fix the underlying vulnerabilities or flaws in web applications, they can prevent attacks that attempt to exploit these flaws from ever reaching the application. WAFs make it challenging for attackers by stopping initial probes, blocking common avenues of attack and rate-limiting requests.

In addition, web application firewalls can log web application traffic, attack attempts and steps taken by a business to secure their web apps — all of which support auditing and compliance activities.

Understanding the Threat Landscape

Before we talk about the critical components of an effective web application firewall, let’s consider the different types of threats against your web application. We’ve already mentioned XSS, SQL injection and local file inclusion. The objective of the original application firewalls was to protect against these types of attacks, but the battlefield has changed and continues to evolve.

Denial of service or DoS and DDoS attacks are becoming more frequent as on-demand cloud computing increases in popularity.

The most recent OWASP Top 10 list now includes more risks associated with access control and configuration. Broken access control and cryptographic failures occupied the top two spots on the 2021 list. Related problems ranging from security misconfiguration to outdated components have also increased. In addition to protecting your services from attack, you need to prevent sensitive data from accidental exposure.

Functions of an Effective Web Application Firewall

A web application firewall operates through a set of rules or policies designed to protect against vulnerabilities in web-based applications by monitoring and filtering network traffic that use web protocols, particularly HTTP and HTTPS.

We can divide the function of the WAF into two distinct parts: protecting inbound and outbound traffic. The inbound protection functionality of the WAF is responsible for inspecting application traffic from the outside world. As part of protecting the web app from inbound traffic, the WAF needs to identify dangerous activity patterns, suspicious payloads and vulnerabilities.

Because hackers persist and innovate, the nature of inbound attacks changes. WAFs need to operate from a proactive set of security policies that protect against known vulnerabilities in the web app. To filter out various types of malicious traffic, each security policy must be kept current, in step with evolving attack vectors. Web application firewalls are especially effective because they are designed for security policy modifications.

Outbound protection is about preventing enterprise and customer data from leaking. Although accurate parsing of outbound data is challenging in the real world, proxy-based, inline WAFs can intercept outbound data and mask or block sensitive data from leaking either through accidental or malicious means.

Different Types of Web Application Firewalls

When using WAFs to protect web applications, you define rules that allow, block or monitor web requests based on certain criteria. You can, for example, customize a WAF rule to block incoming requests that contain a specific HTTP header or come from a particular IP address.

Blocklist vs. Allowlist WAFs

In categorical terms, web application firewalls can be distinguished by how they work. A blocklist WAF is based on a negative security model, while an allowlist WAF follows a positive security model:

• Blocklist WAFs are designed to block certain endpoints, or types of traffic, and allow all others.
• Allowlist WAFs work somewhat in reverse to blocklist WAFs, blocking all traffic by default and allowing only traffic explicitly approved to pass.

Allowlist WAFs are considered more secure because they minimize the risk of malicious traffic evading defenses due to improperly configured firewall rules. That said, allowlist WAFs don't work well in situations where you can’t anticipate all valid traffic types or endpoints.

Given the advantages and disadvantages of these two WAFs, it’s not surprising that many WAFs now operate from a hybrid “allowlist-blocklist” security model.

Network-Based, Host-Based and Cloud-Based WAFs

WAFs can be categorized based on their deployment model — network-based, host-based and cloud-based.

• Network-based: A network-based WAF — in the form of a hardware appliance that has to be licensed and maintained — operates on networking infrastructure (such as a switch) that sits between applications and the internet.
• Host-based WAF: Host-based WAFs are colocated on the servers where the web applications reside. Since they are deployed as a part of the OS of the application, they use OS-level filtering to filter traffic passing to web apps, which can scale easily.
• Cloud-based WAF: Applications hosted in the cloud can use a cloud-based WAF, which integrates with cloud virtual networking services or load balancers to filter web traffic. While cloud-based WAFs don’t require a large team to deploy or maintain, they typically don’t offer complete context into threats.

The WAF deployment model a business uses depends in part on where its web applications reside. A cloud-based WAF, for example, only works when apps are deployed in the cloud. If maintenance is a consideration when choosing a deployment model, network- and host-based WAFs usually require more setup and management, whereas cloud-based WAFs need little more than a DNS or proxy change.

WAFs vs. Other Security Tools

Web application firewalls offer functionality that makes them unique to other firewalls and security solutions, but they aren’t intended to serve as an all-inclusive security tool. In fact, WAFs aren’t built to fend off every type of attack. A web application firewall is but one component of security and is designed to complement an integrated suite of tools to provide a holistic defense against all conceivable attack vectors.

WAFs vs. Traditional Firewalls

Traditional firewalls are designed to define a perimeter that separates resources that operate on an internal network from those that interface directly with the internet. WAFs are more nuanced in that they allow applications to interface with the internet while still providing a layer of protection.

WAFs vs. Next-Generation Firewalls

A next-generation firewall (NGFW) is a type of application firewall that combines the best features of a traditional network firewall and a WAF. In addition to blocking incoming requests by inspecting the network layer packets, the NGFW has inspection capabilities that unlock means to block unwanted traffic on your private network.

Though NGFW and WAF functionality overlap, key differences lie in their core responsibility models. Next-generation firewalls capture more network traffic context and enforce user-based policies, as well as adding essential capabilities, such as antivirus and antimalware. Also, by adding context to security policies, NGFWs can combine threat intelligence engines to assist in the decision-making process.

By contrast, WAFs are confined to the application layer. They specialize in preventing the common web attack, such as a XSS or DDoS attack, making them vital to securing internet-facing and cloud-native applications.

But the overarching difference between the two technologies is best understood in terms of proxies. Used by servers, the WAF is almost always a reverse proxy. NGFWs are used by and designed to protect the clients, which makes them forward proxies in most cases.

WAFs vs. Intrusion Prevention Systems

Like a WAF, an intrusion prevention system (IPS) is designed to identify and block malicious network traffic. IPS, though, are designed to filter all types of traffic across all protocols.

That said, WAFs typically offer more sophistication in their ability to detect complex attacks that operate over web protocols. IPS solutions usually rely on generic attack signatures (specific types of packets or traffic patterns) and do not make extensive use of contextual data (historical traffic patterns or user-behavior patterns) to determine which traffic might be malicious.

How to Deploy a Web Application Firewall

A WAF can be deployed in several ways, depending on where your applications are deployed, the services needed, how you want to manage it, and the level of architectural flexibility and performance required.

Questions to consider:

• Do you want to manage the WAF yourself, or do you want to outsource the management?
• Is a cloud-based model a better option, or do you want your WAF on-premises?

How you want to deploy will help determine which WAF is right for you. You’ll then need to decide how to integrate the WAF into your web app networking stack. You have three approaches to choose from:

• Transparent bridge: In transparent bridge mode, the WAF is bound to the same ports as the web applications it protects. From the perspective of both web apps and clients that connect to them, there doesn’t appear to be a firewall in place, but the port-binding works behind the scenes to allow the WAF to intercept traffic and decide whether to allow it to pass.
• Transparent reverse proxy: Under a transparent reverse proxy approach, the web applications are aware of the existence of a firewall, but clients aren’t. The WAF accepts traffic on ports and addresses that appear to external endpoints as applications, but the applications themselves operate on different, internal ports and addresses. The WAF inspects traffic and decides whether to forward it to those ports and addresses.
• Reverse proxy: A reverse proxy means that clients send requests to a WAF that operates on ports or addresses used to run a proxy service, and then forwards requests to applications. A reverse proxy is similar to a transparent reverse proxy, the main difference being that clients are aware a proxy server exists when a simple reverse proxy is in place.

The transparent bridge model is easiest to implement because it requires the fewest network bindings, addresses and port configurations. It doesn't isolate web apps from the WAF at the network level though. Transparent reverse proxies and reverse proxies provide more isolation and ability to inspect traffic before it reaches applications.

Next in the step of deploying a WAF is choosing where to host it. The main options are:

• Cloud-based as a fully managed service: The WAF runs in the cloud as a fully managed service. Users simply turn it on and configure it, with no management required other than setting up the desired networking policies.
• Cloud-based and self-managed: The WAF is hosted in the cloud, but users are responsible for deploying, configuring and managing it.
• Cloud-based and auto-provisioned: The WAF is hosted in the cloud. Although users have to configure and manage it, it’s automatically populated with networking rules designed to match the cloud environment. This approach offers a middle ground between fully managed and self-managed WAF options.
• On-premises advanced WAF: The WAF is hosted by on-premises infrastructure. On-prem involves more setup effort, and businesses have to provide the host infrastructure for the WAF. The tradeoff is greater control over how the WAF is configured.
• Agent or agentless host-based WAFs: The WAF runs on host servers or application containers. Users may need to deploy agents to each server to host the web application firewall service, but agentless approaches with firewall rules enforced are available.

What to Consider When Choosing a Web Application Security Solution

Factors to consider when evaluating web application firewall options:

• Which deployment models are supported? The best WAFs support a range of deployment options so that they can operate on-premises or in the cloud, using either fully managed or self-managed approaches, depending on options that suit the business.
• How does the WAF filter traffic? The more context a WAF can factor in when evaluating traffic, the better its ability to detect sophisticated attacks that tend to elude generic firewalls.
• How efficient does the WAF need to be? All WAFs should operate efficiently to avoid depriving applications of the infrastructure resources they need to run.

In addition to the above considerations when choosing a web application security solution, it's wise to factor in scalability. How will the WAF need to expand in the future? Will it need to support applications that operate across hybrid and multicloud architectures? Will it need to support APIs? As APIs grow more central to app-to-user communication, the ability to protect APIs as well as web applications will be critical.

Future of Web App and API Security (WAAS)

Modern web applications built on cloud-native architectures are more complex than ever. Agile development processes, continuous integration and deployment, and evolving environments create new challenges for the traditional WAF. The next generation of web application and API protection is web app and API security (WAAS).

WAAS includes traditional WAF features like automatic discovery of web applications. It also goes a step further to discover all API endpoints within your environment. This approach simplifies configuring security rules to protect your web applications and APIs or update existing applications within your environment.

Figure 2: Shift from monolithic application to modern cloud-native application

By automatically detecting and protecting your web-facing applications and APIs, you also reduce the risk that an application might be misconfigured or deployed without protection.

An effective WAAS solution will accept API specifications from various formats, such as Swagger and OpenAPI, and use these definitions to screen requests to determine conformity with the specification. Some endpoints may require less protection and greater access, while those handling sensitive data will require the highest level of protection and scrutiny. In addition, a WAAS solution includes DoS protection out of the box.

Other features you should consider when selecting an application security solution include the ability to screen requests based on place of origin. You also want the ability to customize the level of the defensive measures applied for each application or API with custom rules. You may also want to set the level of alerting and error reporting from each application based on a combination of severity and potential risk.

Securing Your Apps for the Future

As cloud computing solidifies its place in industry, cloud-native applications continue to proliferate while increasing in both importance and complexity. Security must have the ability to evolve as quickly as the dynamic threat landscape.

Information security professionals — DevOps engineers, security architects, and application security teams — will need to collaborate and draw on each other’s experience to build a comprehensive security strategy capable of defending the modern enterprise.

WAF FAQs