WAF or No WAF: What a Web Application Firewall Actually Blocks

Send a URL parameter like ?id=1' OR '1'='1 at a site with no web application firewall, and that string travels straight to whatever code is waiting to process it. Send the same string at a site sitting behind a properly configured WAF, and it never gets there at all, the request gets rejected at the edge, before your application, your database, or your logic ever sees it.

That's the entire job of a WAF in one sentence: it's a filter that inspects incoming HTTP traffic and blocks the requests that look like known attack patterns, before they reach your server. It's also one of the most misunderstood pieces of the security stack, partly because "we have a WAF" gets treated as a finished sentence when it's actually the start of a much longer one.

What a WAF Actually Sits In Front Of

When deployed inline, a WAF sits between the internet and your application and inspects incoming HTTP requests before they reach the application. Depending on how it's deployed, that might mean a cloud service in front of your DNS (Cloudflare, AWS WAF, Akamai), a module running inside your web server (ModSecurity), or an appliance in front of your infrastructure. In all cases, the job is the same: look at each request, compare it against a set of rules or signatures, and decide whether to let it through, block it, or challenge it.

It's not analyzing your application's logic. It doesn't know what a valid order looks like in your specific checkout flow, or what a legitimate user of your product actually does. It's pattern-matching against known attack shapes, which is both its strength and the exact edge of its usefulness.

What It Actually Blocks

A reasonably configured WAF stops a specific, well-understood set of attack patterns:

• SQL injection strings in URL parameters or POST bodies, the classic ' OR '1'='1 and its many variants.
• XSS payloads, <script> tags, javascript: URIs, and their encoded or obfuscated forms.
• Path traversal sequences, attempts to climb out of a web root using ../../../etc/passwd style patterns.
• Command injection patterns, characters and sequences (;, &&, |, backticks) used to chain shell commands into an input field.
• Automated scanning and bot traffic, the kind of aggressive, high-volume probing tools like SQLMap and Nikto generate.
• Known exploit payloads, requests matching signatures for specific, documented CVEs.

This is real, meaningful protection. A site with no WAF and an unpatched vulnerability is directly exposed to anyone running an automated scanner against it. A site with a WAF gets a layer of filtering between "someone tried something malicious" and "that malicious thing reached the application."

Where It Stops Helping

Presence doesn't mean correct configuration. A WAF that's installed with default rules, or with broad exceptions carved out to stop it from blocking legitimate traffic, can end up providing far less protection than its presence implies. Detecting that a WAF exists tells you nothing about whether its ruleset is actually doing its job.

It's not a substitute for fixing the underlying vulnerability. A WAF blocking known SQL injection patterns doesn't mean the query itself is safe from injection, it means the obvious attack strings are being filtered before they arrive. A new or slightly different payload that doesn't match the WAF's signatures can still reach the same unpatched code underneath.

Knowing the vendor can help an attacker as much as it helps you. WAF fingerprinting isn't hard, and once someone knows which vendor is in front of a site, they know which documented bypass techniques to try. Cloudflare-specific evasion patterns, Unicode-encoded SQL injection sequences designed to slip past a particular regex ruleset, these exist publicly because security researchers publish them, and attackers read the same research.

A WAF only sees traffic that actually goes through it. This is the biggest gap, and the one teams miss most often.

The Bypass Nobody's Watching For: The Origin IP

Here's the scenario that makes a WAF's protection completely irrelevant without anyone doing anything sophisticated: a site runs behind Cloudflare, which is correctly configured and actively filtering malicious traffic. But the origin server's real IP address is still discoverable, through DNS history, an old A record that never got cleaned up, a subdomain that points directly at the server instead of through the CDN, or a certificate that was issued before the site moved behind the WAF.

If the origin IP is reachable directly, an attacker skips the WAF entirely by sending requests straight to the server's IP address instead of the domain name. Every rule, every filter, every signature the WAF was enforcing never gets a chance to run, because the traffic never passes through it. The WAF is still working exactly as configured. It's just not in the path anymore.

This is the same category of exposure covered in DNS and subdomain hygiene generally: an old record nobody cleaned up quietly undoes a protection that looks, from the dashboard, like it's fully in place.

How to Check What You Actually Have

Confirm a WAF is present at all. On an application you are authorized to test, send a harmless test request containing a known attack-pattern string to a non-critical endpoint and observe whether it is blocked. Most major WAF vendors return a distinctive block page or status code that's straightforward to recognize once you've seen it.

Check whether the origin is reachable directly. Look up your domain's DNS history for old A records. Check certificate transparency logs (the same crt.sh approach used for finding forgotten subdomains) for certificates that might have been issued directly against the origin. If you find an IP address that responds the same way your main site does, without going through the CDN, that's the bypass sitting open.

Don't stop at "yes, we have one." Ask what it's actually configured to block, whether it's running in monitoring-only mode or actively enforcing, and whether it's been tested against the specific vulnerability classes your application is most exposed to.

When a WAF Is Worth Having

A WAF can serve as a fast additional layer that filters many automated and common attack attempts against public-facing applications. It buys time against known, signature-matched attacks while the actual vulnerability underneath gets fixed properly. For applications that can't patch instantly, it's a genuinely useful stopgap.

What it was never designed to be is the only layer. Secure code, patched dependencies, correct input validation, and an origin that isn't directly reachable all matter more than which vendor's logo is on the WAF dashboard.

Final Thoughts

"We have a WAF" answers one question and leaves several others unasked: configured how, blocking what, and sitting in front of what, exactly. A web application firewall is a real, useful filter for a specific category of attack traffic, not a statement that the application behind it is secure.

The gap that actually matters most is the one nobody's watching: an origin server that's still reachable directly, quietly making an otherwise well-configured WAF irrelevant. Checking for that takes minutes. Assuming it isn't there is the expensive mistake.