WAF and Vulnerability Scanning: How Web Application Firewalls Affect Your Scan Results
A Web Application Firewall sits in front of your application and blocks suspicious traffic before it reaches your origin. That includes traffic from vulnerability scanners — even authorized ones. When the WAF challenges or blocks our probes, DriftAlarm cannot test the underlying app, and your scan report shows fewer findings than the actual surface contains. This guide explains why that happens, how to read DriftAlarm's WAF banner, and the customer-trust-preserving way to get full coverage without weakening your defenses.
- How WAFs interact with external vulnerability scanners
- The three coverage modes: full, WAF-limited, and authenticated
- How to read the DriftAlarm WAF banner and what each vendor's challenge looks like
- How to allowlist authorized scanners in Cloudflare, Vercel, Akamai, and AWS WAF
- Why allowlisting your scanner does not weaken your defenses against attackers
The Short Answer
If your DriftAlarm asset shows a yellow or red WAF banner, it means more than half of our probes against your application returned challenge or block responses from a Web Application Firewall — Cloudflare, Vercel, Akamai, AWS WAF, F5, Imperva, Fastly, or Azure App Service. The scanner is working correctly. So is your WAF. The scan report reflects only the WAF-bypassable surface of your application; everything behind the WAF is invisible to external probes.
You have three choices: accept the limited coverage as confirmation that your edge defenses are working, allowlist DriftAlarm's scanner so we can probe the full application, or move to authenticated scanning where we use your session cookies to test the post-login surface. Most security teams choose to allowlist authorized scanners — it gives full visibility for you without weakening defenses against real attackers.
How WAFs Affect Vulnerability Scans
A Web Application Firewall inspects incoming HTTP requests and applies rules to decide whether to let them through, challenge them, or block them. Modern WAFs combine signature matching, behavioral analysis, IP reputation, TLS fingerprinting, and rate limiting. Most ship with default rules that flag traffic from known scanner IPs, requests carrying scanner User-Agent strings, and patterns that resemble probes for common vulnerabilities like SQL injection or path traversal.
When DriftAlarm's scanner sends probes against an application behind a WAF, one of four things happens to each probe:
- Pass through: The WAF allows the request and our scanner sees the real application response. We can test for vulnerabilities on this surface.
- Challenge: The WAF returns an interactive challenge page (Cloudflare's "Just a moment...", Vercel Security Checkpoint, Akamai's Bot Manager challenge). Headless scanners cannot solve these challenges, so the response we see is the challenge page — not the application.
- Silent block: The WAF returns a generic 403 Forbidden or 503 Service Unavailable without revealing why. Cloudflare's custom firewall rules and AWS WAF default actions often work this way.
- Rate limit: The WAF accepts initial probes but starts returning 429 Too Many Requests after a threshold. DriftAlarm already throttles to 50 requests per second when WAF presence is detected, but rate-limit-only WAFs are uncommon — most challenge or block based on signature, not rate.
Each probe that gets challenged or blocked is a probe that didn't reach your application, so DriftAlarm cannot test that endpoint for vulnerabilities. If 87% of probes return the Vercel Security Checkpoint, we have meaningful scan data on only 13% of your URLs. The risk score and finding counts reflect that 13% — the real attack surface behind the WAF is invisible to our scan.
A scanner that gets WAF-blocked is doing exactly what it should: respecting your edge defenses. The same posture that protects you from automated attacks also limits what authorized scanners can see. The fix is not a stronger scanner — the fix is to give authorized scanners explicit permission to bypass the WAF, while keeping protection against everything else.
Three Coverage Modes
DriftAlarm coverage falls into one of three modes depending on how your application is configured and whether you've taken steps to grant the scanner access:
1. Full Coverage
No WAF in front of the application, or the application is internally exposed without an edge firewall. DriftAlarm probes every reachable URL and tests for vulnerabilities directly. Risk scores reflect the actual surface. This is the typical mode for IP-routed services, staging environments without WAF protection, and applications behind only a CDN cache (no WAF rules).
2. WAF-Limited Coverage
A WAF challenges or blocks our probes. DriftAlarm sees only the WAF response, not the application. The asset detail page shows a yellow or red WAF banner identifying the vendor and the percentage of blocked probes. Findings reflect only the WAF-bypassable surface — typically less than 25% of the actual application. This is the default state for production sites behind Cloudflare bot fight, Vercel checkpoint mode, AWS Shield Advanced, or similar.
3. Authenticated / Allowlisted Coverage
Either DriftAlarm has been allowlisted in your WAF (probes pass through to the application) or DriftAlarm has been provided with valid session credentials (probes are made as a logged-in user, often bypassing many WAF rules tied to anonymous traffic). This is the most accurate mode and matches what an authenticated attacker would see if your credentials leaked.
Most production assets at small and mid-sized businesses run in mode 2 by default. Mode 3 requires a one-time setup but pays for itself in finding-density: customers who allowlist our scanner typically see 5x to 20x more findings on the same asset.
Workarounds: Allowlisting Authorized Scanners
The cleanest way to get full coverage is to allowlist DriftAlarm's scanner egress in your WAF. This tells your WAF to let our specific traffic through to the application, while keeping all other rules active for the rest of the internet. Each major WAF vendor supports scanner allowlisting through different mechanisms.
DriftAlarm currently uses a shared dynamic egress for the scanning fleet. To allowlist us reliably, you'll need a dedicated static IP that we route your scans through. This is available on request — contact us at contact@driftalarm.com with your asset domain(s) and we'll provision a dedicated egress and share the IP for your allowlist rule. There's no extra charge on Pro tier; turnaround is typically a few business days.
Cloudflare
Cloudflare supports scanner allowlisting via IP Access Rules or by creating a custom firewall rule with a "Skip" action for your scanner's IP. The simplest approach is to add an IP Access Rule with action "Allow" scoped to the relevant zone or account.
- Cloudflare documentation: IP Access Rules
- For more granular control with WAF rule skipping: Skip action for custom rules
Allowlisting at the account level rather than per-zone is faster if you have many domains on Cloudflare.
Akamai
Akamai's bypass approach depends on your product (Kona Site Defender, App & API Protector, Bot Manager). The most common pattern is a Network List allowlist combined with a match target rule that exempts traffic from that list.
- Akamai documentation: About Network Lists
- For Bot Manager exemptions: Bot Manager documentation
Vercel
Vercel's firewall (formerly Attack Challenge Mode) supports IP allowlisting through Firewall > Rules in the project dashboard. Create a rule with action "Allow" and the condition matching DriftAlarm's egress IP.
- Vercel documentation: Vercel Firewall
- Custom rules and IP allowlists: Custom rules
AWS WAF
AWS WAF allowlisting is done by creating an IP set containing the scanner's IP, then adding a rule to your Web ACL that allows traffic matching that IP set, placed earlier in the rule priority than your blocking rules.
- AWS documentation: Creating an IP set
- Rule priority and matching: Web ACL rule actions
Other WAFs (Imperva, F5, Fastly, Azure)
All major WAF vendors support IP allowlisting through similar mechanisms — either an IP allow list, an exemption rule, or a "trusted source" group. Refer to your vendor documentation, or contact contact@driftalarm.com and we can help you find the right setting for your specific product.
Important Caveat: WAFs Still Protect You
Allowlisting DriftAlarm's scanner does not weaken your defenses against real attackers. The allowlist rule is scoped to a single, dedicated IP that only DriftAlarm uses. Every other source — including all attacker traffic — still hits the full WAF rule set. The WAF continues to block automated attacks, brute force attempts, signature-based exploits, and anomalous behavior from anywhere except our specific IP.
What allowlisting does change is your scan visibility: DriftAlarm sees the same surface an authenticated, well-behaved client would see. That surface is precisely what an attacker would target if they obtained valid credentials, bypassed your WAF through a zero-day, or compromised an internal source already inside your trusted network. Knowing about those vulnerabilities gives you the chance to patch them before someone else uses them.
Think of WAF-blocked scans as showing your perimeter view and allowlisted scans as showing your interior view. Both are useful. Most security teams want both: they keep the WAF active to deflect everyday attacks, and they allowlist authorized scanners to find what's broken on the inside before someone with a foothold does.
When to Consider Authenticated Scanning
Allowlisting DriftAlarm's scanner gives us full reach to your application's surface, but it doesn't get us past authentication walls. If your application's main risk surface is behind a login (think customer dashboards, admin portals, internal tools fronted by SSO), allowlisting alone won't reveal what's reachable post-auth.
Authenticated scanning solves this by letting DriftAlarm probe with valid session cookies or tokens you provide. The scanner makes requests as a logged-in user, exposing the post-auth attack surface that regular external scans never see.
DriftAlarm's authenticated scanning is on the roadmap and not yet generally available. If your security program needs authenticated coverage, reach out at contact@driftalarm.com and we'll add you to the early-access list and prioritize accordingly.
Frequently Asked Questions
Why does my DriftAlarm scan show fewer findings on a WAF-protected site?
When a WAF challenges or blocks our probes, the scanner cannot test the underlying application. Findings only reflect the small portion of your surface that the WAF allows through. The WAF banner on the asset detail page tells you exactly what fraction was blocked and which vendor is doing the blocking.
Should I allowlist DriftAlarm's scanner in my WAF?
For most security teams, yes. Allowlisting gives you full visibility into your application without weakening defenses against attackers (the allowlist rule is scoped to a single dedicated IP we use). If you only want a perimeter view of what's externally exposed, keeping DriftAlarm WAF-limited is also a valid choice — the WAF banner makes the limited coverage transparent.
Does DriftAlarm try to bypass WAFs?
No. We surface WAF blocking so you can see it; we don't attempt to evade it. Techniques like JA3 fingerprint randomization, distributed source IPs, or solving JavaScript challenges violate most WAF vendor terms of service and would erode trust. The legitimate paths for full coverage are allowlisting and authenticated scanning — both customer-driven.
How do I know if a WAF is limiting my scan results?
DriftAlarm shows a yellow banner at 50% blocking and a red banner above 90%. Scan history rows are tagged "WAF-limited" when the asset is currently behind a heavy WAF posture. The asset list page also tooltips the risk badge with the WAF coverage note.
Will the WAF banner go away if my customer adds an allowlist rule?
Yes. Once allowlisted, our daily vuln-scan sees the application directly, the WAF-blocking fraction drops below 50%, and after three consecutive low readings the sticky-display banner clears. The transition takes a few days because DriftAlarm intentionally smooths out single-scan blips to keep the banner state stable.
What WAFs does DriftAlarm detect?
DriftAlarm currently identifies eight WAF families: Cloudflare, Vercel, Akamai, AWS WAF, Imperva (Incapsula), F5 BIG-IP ASM, Fastly, and Azure App Service. Each is matched by response signatures (CDN name, status code, and challenge page title). If you see a generic "WAF" label rather than a specific vendor, it usually means the response signature doesn't match a known pattern — let us know and we'll add it to the detection rules.
Get Full Coverage Today
If your DriftAlarm scan is showing limited coverage because of WAF blocking, allowlisting is the fastest path to full visibility. Contact us and we'll provision a dedicated scanner egress IP for your account so you can add a single, scoped allowlist rule to your WAF.