Web Application Firewalls: What They Stop and What They Miss

A guard at the door, not a fix for the building

A web application firewall (WAF) sits in front of a web application and inspects the HTTP traffic flowing to it, deciding what to allow and what to block. Unlike a traditional network firewall, which reasons about ports and IP addresses, a WAF understands the application layer — it reads requests, parses parameters, examines headers and payloads, and looks for the patterns of a web attack. When it sees SQL injection in a query string or a cross-site scripting payload in a form field, it blocks the request before it ever reaches the application.

That capability is genuinely valuable, and it is easy to overstate. A WAF is a guard checking people at the door, not a repair to the building's structural flaws. It can stop many attacks from reaching a vulnerable application, but it does not make the application not vulnerable. Understanding a WAF means being precise about both halves: the real protection it provides, and the significant categories of risk it does nothing about. Deployed with clear expectations, it is a strong layer of defense. Sold as a substitute for secure code, it becomes false comfort.

What a WAF genuinely stops

Within its lane, a WAF is effective, and its lane covers a meaningful share of real-world web attacks — much of the OWASP Top 10 territory. The attack classes it handles well:

• Injection attacks. SQL injection, command injection, and similar payloads have recognizable signatures a WAF can detect and block. This is core WAF functionality and stops a large volume of automated attacks.
• Cross-site scripting (XSS). Malicious scripts injected into input fields or parameters, matched against known patterns.
• Common automated attacks. The constant background noise of the internet — bots probing for known vulnerabilities, credential-stuffing runs, scanners hunting for exposed admin panels and known CVEs in web frameworks. A WAF filters much of this out before it consumes application resources.
• Virtual patching — often the most valuable use. When a critical vulnerability is disclosed in a framework or component you run, you frequently cannot deploy a code fix immediately — testing and release cycles take time. A WAF rule that blocks the specific exploit pattern buys you protection in the meantime. This ability to shield a known-vulnerable application while a real fix is prepared is one of the strongest practical arguments for running a WAF, and it ties directly into vulnerability management.
• Rate limiting and request throttling. Capping abusive request volumes helps against brute-force and application-layer denial-of-service attempts.

For an internet-facing application, a WAF removes a large amount of low-sophistication attack traffic and gives you an emergency control when a new exploit appears. That alone justifies it in most environments.

Figure: a WAF inspects HTTP requests at the application layer and blocks recognizable attack patterns — but it filters traffic in front of the app, without changing the flaws that live inside it.

What a WAF misses

The limitations are as important as the capabilities, because misunderstanding them leads to breaches that everyone assumed the WAF would prevent.

• Business logic flaws. A WAF has no idea what your application is supposed to do. If your app lets a user change an account number in a request and view someone else's data (an authorization flaw), every request is perfectly well-formed HTTP. There is no malicious signature to match — the attack is abusing legitimate functionality. WAFs are largely blind to this entire category, which includes some of the most damaging real-world breaches.
• Broken access control and authentication. Insecure direct object references, privilege escalation, and flawed session handling exploit the application's own logic. The requests look normal; the WAF passes them.
• Zero-days and novel techniques. Signature-based detection catches known patterns. A genuinely new attack, or a known attack obfuscated cleverly enough, can evade the ruleset. Attackers actively research WAF-evasion encodings.
• Encrypted and internal blind spots. A WAF must be able to decrypt TLS to inspect traffic; if it is not terminating or decrypting properly, it sees nothing. It also does nothing for vulnerabilities exploited through paths that do not traverse it.
• Everything below the request. Vulnerable dependencies, exposed secrets, misconfigured cloud storage, and flaws in APIs the WAF does not front are all outside its view.

The through-line is simple: a WAF pattern-matches on the traffic, so it excels against attacks with recognizable payloads and is weak against attacks that abuse legitimate application behavior. The most serious application breaches often fall in the second category.

Tuning is the whole job

A WAF is not a device you switch on and forget. Its effectiveness lives entirely in how it is configured and maintained, and the central difficulty is the balance between blocking attacks and blocking customers.

• False positives are the core tension. Rules too aggressive block legitimate users and break application features; rules too loose let attacks through. Every application is different, so out-of-the-box rulesets always need tuning to the specific app's normal behavior.
• Start in monitoring mode. Deploy a new WAF or ruleset in detection-only (log, don't block) mode first, observe what it would have blocked against real traffic, and confirm you are not about to break legitimate functionality before you switch to blocking.
• Tune continuously. Applications change with every release — new endpoints, new parameters, new workflows. A WAF configuration that fit the app six months ago drifts out of alignment. Tuning is ongoing operational work, not a deployment task.
• Beware the fragile bypass. Attackers who find their payload blocked will try encoding tricks, alternate parameters, and protocol quirks to slip past the rule. A ruleset that stops the textbook version of an attack may not stop a determined attempt.

An unmaintained WAF drifts toward one of two failure modes: so noisy the team disables rules until it protects nothing, or so aggressive it becomes an availability problem of its own. Neither is the WAF's fault — both are the absence of the operational discipline a WAF requires.

Where it fits in a defense-in-depth program

The correct mental model is that a WAF is one layer, valuable precisely because it is not the only one. It compensates for the reality that no application is perfectly secure by filtering attacks in front of it, while the durable fixes happen elsewhere.

The layers a WAF should sit alongside:

• Secure development and testing. The real remedy for application vulnerabilities is not shipping them. A mature application security program — secure coding, code review, and testing in the pipeline — fixes flaws at the source. The WAF covers the window before a fix ships and the flaws that slip through anyway.
• Finding what you actually expose. A WAF only protects the applications it fronts. Attack surface management ensures you know about every internet-facing app in the first place — the forgotten staging site with no WAF in front of it is the one that gets breached.
• Detection and response behind the filter. A WAF blocks some attacks and logs the rest; those logs are a rich detection source. Feeding WAF telemetry into monitoring means the attacks it didn't block still generate a signal a response team can act on.
• API-specific protection. As traffic shifts from browsers to APIs, dedicated API security controls address gaps a traditional WAF handles poorly.

A WAF at the edge, secure code underneath, exposure managed around it, and detection behind it — that is defense in depth. Any one of those alone leaves a gap the others cover.

Where to start

Put a WAF in front of every internet-facing application, but deploy it in monitoring mode first, learn each app's real traffic, and move to blocking deliberately so you protect customers instead of blocking them. Use virtual patching as a first-class capability — when a critical web vulnerability drops, a WAF rule is your fastest shield while the code fix is tested. Above all, hold the right expectation: the WAF buys time and filters noise, while the durable work is fixing the flaws inside the application.

intSignal deploys and operates WAFs as one layer of a broader application security practice — tuned to your applications, integrated with virtual patching and detection, and paired with the secure-development and exposure work that addresses the flaws a WAF was never meant to fix. Talk to our security team and we will help you see what your WAF is catching, and what is walking straight past it.