A hospital's patient portal has a SQL injection flaw that the vendor won't patch until next month. A billing clerk drags a spreadsheet of 4,000 patient records into a personal webmail tab. A nurse working from home clicks a link to a phishing site that the office web filter would have blocked. Each problem travels over ordinary HTTPS, and each needs a control that looks at content, not just addresses and ports.
On the CompTIA Security+ SY0-801 exam these tools sit under objective 4.1, which lists the web application firewall with the other firewalls and groups content filtering with data loss prevention, agent-based filtering and the centralized proxy. This lesson covers what a WAF blocks and how virtual patching works, the difference between forward and reverse proxies, centralized versus agent-based content filtering, the trade-offs of TLS inspection, and DLP on the network and on the endpoint.
A web application firewall inspects HTTP requests for attacks on the application
A web application firewall (WAF) sits in front of a web application and parses each HTTP request: the URL, query string, headers, cookies and body, including form fields and JSON. A network firewall that allows TCP 443 sees none of that. The WAF looks for the attack classes behind the OWASP Top 10 list of web application risks: SQL injection, cross-site scripting, path traversal, command injection and file inclusion, along with malicious bots, protocol abuse and excessive request rates.
WAFs are deployed as a reverse proxy appliance, as a cloud service in front of the site, or as a module inside the web server; ModSecurity is the long-standing open-source example. Many WAFs use the OWASP Core Rule Set, an open rule set that scores each request for suspicious traits and blocks it when the score passes a threshold. A blocked request looks like this in the log:
2026-10-21T14:03:17Z waf action=BLOCK status=403 rule=942100 msg="SQL Injection Attack Detected via libinjection"
client=198.51.100.23 method=GET uri="/products?id=1' OR '1'='1"
Rules follow one of two models. The negative security model blocks known-bad patterns, which is easy to start with but misses new tricks. The positive security model allows only known-good input, such as a parameter that must be a number of up to six digits, which is stronger but takes work to define for every page.
Two practical points matter. A WAF must see decrypted traffic, so it either terminates TLS itself, holding the site's certificate and private key, or runs inside the web server after decryption. And new WAFs usually run in detection mode first, logging what they would block, because a rule that blocks a legitimate form submission is an outage. A WAF reduces risk; it does not replace secure coding, which is covered in the application security section.
Virtual patching blocks an exploit at the WAF until the code is fixed
When a vulnerability is published in a web application, the fix may be weeks away: the vendor hasn't released it, or it needs testing and a change window. Virtual patching closes the gap by writing a WAF rule that blocks requests exploiting that specific flaw, so the vulnerable code never receives them. For a path traversal bug in an export feature, a ModSecurity rule might look like this:
SecRule REQUEST_URI "@beginsWith /api/export" \
"id:10001,phase:2,deny,status:403,log,msg:'Virtual patch: traversal in export file parameter',chain"
SecRule ARGS:file "@contains ../" "t:none,t:urlDecodeUni"
Virtual patching buys time; it is not a fix. The flawed code is still there, and an attacker who finds an encoding the rule doesn't anticipate can get past it. Record the rule as a compensating control with an owner and an expiry date, install the real patch when it arrives, then remove the rule.
On the exam, "a patch is not yet available" or "the application can't be modified" combined with a web attack points to a WAF virtual patch. An IDS that alerts on the exploit is the usual distractor, because alerting doesn't stop the request.