WAF Explained: Web Application Firewalls for the Security+ Exam

A web application firewall sits in front of a web application and inspects HTTP and HTTPS traffic, blocking requests that look like attacks. The key word is application — it understands web requests, not just packets.

A network firewall decides whether traffic may reach port 443. A WAF decides whether the request arriving on port 443 is trying to attack you.

That distinction is the most tested point on the topic. A traditional firewall filters on IP addresses, ports and protocols — layers 3 and 4. It has no idea what is inside the HTTP request, so a SQL injection payload passes through untouched because it arrives on an allowed port. A WAF operates at layer 7 and parses the request itself: the URL, headers, parameters, cookies, and body.

What It Blocks

WAFs are aimed squarely at the OWASP Top 10 and similar application attacks:

• SQL injection and other injection attacks.
• Cross-site scripting (XSS).
• Directory traversal and local file inclusion.
• Command injection.
• Cross-site request forgery, with the right configuration.
• Malicious file uploads.
• Application-layer denial of service, through rate limiting.
• Bot and scraping traffic.

The Two Security Models

Negative security model (blocklist). Block anything matching known attack signatures, allow everything else. Easy to deploy, works immediately, and misses novel attacks and obfuscated payloads. This is the default for most deployments.

Positive security model (allowlist). Define exactly what valid input looks like for each parameter — this field is an integer between 1 and 999, that one is an email address — and reject everything else. Far stronger, and far more work, because it requires knowing the application intimately and updating the model as the application changes.

Most real deployments run a negative model with positive rules on the highest-risk endpoints. Exams test the distinction, and the general principle that allowlisting is more secure than blocklisting applies here as it does everywhere.

Deployment Modes

• Reverse proxy — all traffic passes through the WAF, which terminates TLS and forwards clean requests. Full inspection and the ability to modify responses, at the cost of being in the traffic path.
• Bridge or inline transparent — sits in the path without being addressed directly.
• Out of band / monitoring — sees a copy of traffic and alerts without blocking. Useful for tuning before enforcement.
• Host-based — a module in the web server itself, such as ModSecurity in Apache or nginx.
• Cloud WAF — a service in front of your application, typically bundled with a CDN and DDoS protection. The common choice today.

A related term: RASP — runtime application self-protection — runs inside the application, which gives it context a WAF cannot have, such as whether a query actually reached the database.

What a WAF Does Not Do

Being clear about this matters, because the exam framing is consistent.

A WAF is a compensating control, not a fix. The vulnerability is still in the code. The WAF is a filter in front of it, and filters can be bypassed — through encoding, case variation, unusual content types, HTTP request smuggling, or simply an attack the signatures do not cover. Secure coding and patching remain the actual remediation.

It also cannot see business logic flaws. A request that lets one user read another's records by changing an ID looks perfectly well-formed, and no signature will catch it.

And it needs to see plaintext, so it must terminate TLS or be given the keys — which puts it in the same architectural conversation as SSL decryptors.

Virtual Patching

One genuinely valuable WAF use worth knowing by name. When a critical vulnerability is disclosed in a framework you use and the real patch needs testing before deployment, a WAF rule blocking the exploit pattern buys time. This is called virtual patching, and it is a legitimate and common response to a zero-day — provided everyone understands it is a stopgap with an expiry date, not the remediation.

Tuning and False Positives

An aggressive WAF blocks legitimate traffic. A user writing "I want to select all the items and drop them" in a support form can trip a naive SQL injection rule. The standard approach is to deploy in detection-only mode first, observe for a period, tune the rules against real traffic, then switch to blocking. Skipping that step is how a WAF deployment becomes an outage.

Security+ (SY0-701) Exam Tips

• A WAF operates at layer 7 and inspects HTTP/HTTPS content. A network firewall works at layers 3 and 4.
• It defends against OWASP Top 10 attacks — injection, XSS, traversal.
• It is a compensating control, not a substitute for secure code.
• Know blocklist versus allowlist — negative versus positive security models.
• Virtual patching as a temporary mitigation for a known vulnerability.
• Know the neighbours: next-generation firewall, IPS, reverse proxy, load balancer, RASP, and API gateway.
• It must terminate or decrypt TLS to inspect encrypted traffic.

PenTest+ and CySA+ Angles

PenTest+ (PT0-003) covers WAF detection and evasion — fingerprinting the WAF, then encoding, case variation, comment insertion and chunked transfer to slip past signatures — all within an authorized scope, and reported as a defense-in-depth finding rather than a claim the WAF is useless.

CySA+ (CS0-004) treats WAF logs as a detection source: reading blocked-request patterns to identify targeted attacks, distinguishing automated scanning from a focused attempt, and using the logs to scope an incident.

Key Takeaways

• A WAF inspects HTTP traffic at layer 7, unlike a network firewall filtering ports and addresses.
• It targets application attacks — injection, XSS, traversal and the rest of the OWASP Top 10.
• Negative model blocks known bad; positive model allows only known good. The second is stronger and harder.
• It is a compensating control. The vulnerability remains in the code.
• Virtual patching buys time while a real patch is tested.
• Deploy in detection mode and tune first, or you will block real users.