WAF Detection: What a Web Application Firewall Means for Your Scan

Run a scan against a protected website and the results carry an asterisk nobody prints: "everything below was observed through a filter whose job is to stop exactly these requests." That filter is the WAF — the Web Application Firewall — and understanding its effect on scanning is the difference between reading a report correctly and over-trusting a clean result.

What a WAF actually does

A WAF sits between the visitor and your origin server, inspecting every request against a ruleset of known-bad patterns:

• 🧬 SQL injection payloads — quote sequences, UNION SELECT, tautology probes
• ⚡ XSS payloads — script tags, event handlers, encoded script fragments
• 📁 Path traversal — ../ sequences, encoded dot-dot variants
• 🤖 Bot and scanner signatures — known tool user-agents, aggressive request rates
• 📦 Known-exploit requests — matching CVE-specific URI patterns

Cloudflare, AWS WAF, Akamai, ModSecurity, F5 — the products differ, the concept is identical: match bad patterns, block or challenge the request.

How a scanner detects a WAF

Detection is behavioral, not branded. Signals a scanner correlates:

When enough signals align, the scan reports: a WAF is present and active on this target. That single finding recontextualizes everything else in the report — which is exactly why we treat WAF detection as a first-class result in our scanner rather than a footnote.

Why a WAF changes scan results

The uncomfortable mechanics:

1. 🔬 A scanner tests for SQL injection by sending a payload that looks like SQL injection
2. 🧱 The WAF sees a textbook attack signature and blocks it
3. 📄 The origin never receives the probe, so no vulnerable behavior is ever observed
4. 📊 The scan reports no SQL injection finding — not because the app is safe, but because the probe never landed

The vulnerability can still exist at the origin. The WAF simply stands in front of it. Any rule gap — a new bypass technique, a misconfigured exception, a legacy rule mode — re-exposes the underlying flaw instantly. This is why security teams treat WAF-protected targets as under-reported, not verified clean.

Reading a WAF-flagged report correctly

When your scan result says a WAF is present:

• ✅ Infrastructure findings remain trustworthy — TLS problems, missing headers, exposed files, and DNS issues are observed on responses the WAF serves, not blocks
• ⚠️ Injection-class findings trend toward under-reporting — treat "none found behind a WAF" as "none reachable through the WAF today"
• 🔁 Re-scan after rule changes — WAF mode switches and new rule sets change visibility overnight
• 🧪 For certainty, test at the origin — allowlisting the scanner's source or testing a staging copy without the WAF gives the unfiltered truth; evidence-verified findings methodology (as we describe in our evidence-verified scanning article) matters even more here

For site owners: the right way to combine WAF + scanning

A WAF is a valuable layer — deployed in minutes, absorbing commodity attacks around the clock. Use it as one layer, deployed with full knowledge of its blind spot:

1. 🧱 Keep the WAF on — it defeats the automated majority of attacks cheaply
2. 🛠️ Fix the findings the scan can see — headers, TLS, exposed content, versions
3. 🔓 Periodically scan the origin directly — staging copies, or production with scanner allowlisting — to see what the WAF hides
4. 📡 Scan on a schedule — WAF rules and origin code both drift; our continuous monitoring re-checks both directions weekly
5. 🚨 Treat WAF block-rate spikes as signal — a sudden burst of blocks is often reconnaissance for a technique your ruleset does not yet know

The mature position on WAFs is neither dismissal nor dependence: it is a shield that blocks the attacks it recognizes, in front of an application you keep fixing anyway. The scanner's job — and ours — is to tell you clearly which of the two worlds each finding came from.