A web application firewall (WAF) is a security control that sits in front of a web application and inspects the HTTP and HTTPS requests sent to it. It compares each request against rules that describe known attack techniques, such as SQL injection, cross-site scripting and attempts to exploit specific software flaws, and blocks or logs requests that match. Its job is to protect the application itself, such as a website, customer portal, online store or API, from attacks that a traditional network firewall would let through as ordinary web traffic.
At a glance
- A WAF filters web requests to an application, looking for attack patterns inside the traffic.
- It is available as a cloud service, a hardware or virtual appliance, or software running with the application.
- Managed rule sets from the provider cover common attack types and are updated as new flaws become known.
- It can temporarily shield a known vulnerability until the application is patched, often called virtual patching.
- WAFs need tuning: rules that are too strict block real users, and rules that are too loose let attacks through.
What problem it solves
Public web applications are exposed to the internet around the clock, and automated tools constantly scan them for weaknesses. Many attacks arrive as normal-looking web requests on the standard web ports, so a network firewall, which mostly decides which connections are allowed, lets them through. The attack is in the content of the request: a crafted form field, a manipulated URL, or a payload aimed at a known flaw in the platform the site runs on.
Few companies can fix every vulnerability in their web applications immediately. Code takes time to change, third-party platforms need vendor updates, and older applications may have no developer left to maintain them. A WAF reduces the exposure in the meantime by blocking common attack patterns before they reach the application, and gives you logs showing what is being attempted. For companies that handle customer data or payments online, it is also a control auditors and customers frequently ask about.
How it works
Placement. A cloud WAF typically sits in front of the application as a reverse proxy: you point your domain’s DNS at the provider, which receives traffic, inspects it and forwards clean requests to your servers. Many cloud WAFs run on the same network as a content delivery network (CDN). Appliances sit in your data center or cloud network in front of the web servers, and some WAFs run as modules on the web server itself.
Inspection. A WAF needs to see requests in plaintext to inspect them. Because most web traffic is encrypted, the encryption has to end somewhere before inspection: at the WAF itself, which then holds your certificates, at an upstream proxy or load balancer that passes decrypted traffic to the WAF, or inside the application stack when the WAF runs as a server module. The WAF then checks each request against rules.
Rules. Many WAFs combine managed rule sets maintained by the provider, covering common categories such as those in the OWASP Top 10, with custom rules you add for your application. Some also use positive security models, allowing only requests that match expected behavior, and rate limits for pages such as login forms.
Actions. Matching requests can be blocked, challenged, logged or allowed. New rules are often run in monitor-only mode first to avoid blocking legitimate users.
Related protections. Many WAF services now include or sell alongside bot mitigation, API protection and distributed denial-of-service (DDoS) protection. What is included varies by provider and tier.
When it matters for buyers
- When you run public-facing web applications or APIs. Customer portals, e-commerce sites and login pages are common targets.
- When a critical vulnerability is announced in software you use. A WAF rule can reduce exposure while you patch, alongside your vulnerability management process.
- When customers, auditors or payment card rules ask about web application protection. Payment card standards, for example, call for protecting public-facing web applications, and a WAF is a common way to meet that; confirm requirements with your assessor.
- When moving applications to the cloud. It’s a natural time to replace an on-premises WAF appliance with a cloud service.
- When comparing CDN or hosting providers. Many include WAF features, with differing depth.
Our web application and API protection overview covers the broader set of controls that often include a WAF.
Questions to ask vendors
- Is the WAF delivered as a cloud service, appliance or software, and where does inspection happen?
- Which managed rule sets are included, and how quickly are rules updated for newly announced vulnerabilities?
- Can we run rules in monitor-only mode, and how do we create exceptions for our application?
- How do you handle our TLS certificates and decrypted traffic?
- Are API protection, bot management and DDoS protection included, or sold separately?
- Who tunes the rules and investigates blocked requests: us, you or a managed service?
- What logs and reports do we get, and can they feed our SIEM?
How it differs from a network firewall and WAAP
A network firewall controls traffic between networks based mainly on addresses, ports, protocols and, on newer models, applications and users. It protects the network as a whole and generally permits web traffic to a public website. A WAF focuses narrowly on web requests to specific applications and inspects their content for attacks. Web application and API protection (WAAP) is the broader bundle: a WAF plus API protection, bot management and DDoS protection, usually in one cloud service. Many products sold as a WAF include some of those extras, so compare features rather than labels.