What is a WAF?
A web application firewall (WAF) is a Layer 7 filter dedicated to web traffic. Placed between users and a web application or API, it reads every part of each HTTP request, from the path and parameters to headers, cookies and posted data such as form fields or JSON, and decides whether to pass it on. A traditional firewall rule that permits TCP 443 only knows which host and port the traffic is headed for. A WAF targets the attack types catalogued in the OWASP Top 10, such as SQL injection, cross-site scripting (XSS), path traversal, command injection and file inclusion, and it can also limit request rates and block malicious bots.
How a WAF works
WAFs come in three common forms:
- Reverse proxy appliance or virtual appliance placed in front of the web servers, often in the screened subnet.
- Cloud WAF, where the site's DNS points at a provider that filters traffic before forwarding it to the origin servers.
- Host-based module running inside the web server, such as the open-source ModSecurity engine.
Encrypted requests are useless to a WAF until they are decrypted, so an appliance or cloud WAF usually ends the TLS session itself using the site's certificate and key, while a host-based module sees each request after the web server has decrypted it.
WAF rules take one of two approaches. Blocking what is known to be malicious is the negative model; the open-source OWASP Core Rule Set (CRS) works this way, scoring each request for suspicious traits and rejecting it once the total passes a threshold. Accepting only what is known to be valid is the positive model, for example rejecting any order ID that is not one to eight digits. The positive model resists new attack tricks better but requires describing the expected input for every page and parameter. Most teams run a new WAF in detection-only mode for a while, since wrongly blocking real customers' requests is an outage of its own.
Example: a blocked request
A search page receives a request with a script in the query string. The WAF log records the match and the 403 response it returned:
action=BLOCK status=403 rule=941100 msg=XSS Attack Detected via libinjection uri=/search?q=%3Cscript%3Ealert(1)%3C%2Fscript%3E client=203.0.113.77
The rule number comes from the CRS cross-site scripting rule group. The request never reached the application, but the page is still vulnerable if it reflects input without encoding it, so the finding also goes to the developers.
Virtual patching
When a flaw in a web application is published and the fixed version is weeks away, a WAF rule written for that specific exploit can block it in front of the application. This is virtual patching. It is a compensating control that buys time, so track the rule like any temporary exception: give it an owner and an end date, and retire it once the vendor's fix is installed.
Log4Shell (CVE-2021-44228) in December 2021 showed both sides. WAF vendors pushed rules matching the ${jndi: lookup string within days, which stopped the simplest early exploit attempts, but attackers quickly switched to obfuscated variants, such as nested lookups, that the first rules missed. A virtual patch buys time while the vulnerable component is updated; it does not replace the update.
WAF vs. network firewall vs. IPS
| Control | What it inspects | Best at |
|---|---|---|
| Network firewall | Addresses, ports and protocols; Layer 7 firewalls add application and user identity | Deciding which traffic may pass between zones |
| WAF | HTTP requests to specific web applications | Stopping injection, XSS and other attacks on a web app |
| IPS | Traffic across many protocols, matched to signatures and anomalies | Blocking known exploits across the network |
A WAF does not replace secure coding. Server-side input validation, output encoding and parameterized queries fix the flaw; the WAF reduces the chance that an attacker reaches it.
WAF on the CompTIA Security+ exam
The WAF appears in SY0-801 objective 4.1 among the firewall types used as mitigating controls. Scenario wording such as SQL injection against the public web portal, protect the web application at Layer 7 or the vendor's fix is weeks away and the code cannot be touched points to a WAF, and the last one to a virtual patch. The usual distractors are an IDS, which only alerts and lets the request through; a network firewall or ACL, which cannot read the HTTP payload; and DLP, which watches data leaving rather than attacks arriving. If a question asks for the fix in the code itself, choose input validation or parameterized queries over the WAF.