WAF and Vulnerability Scanning: How Web Application Firewalls Affect Your Scan Results
A Web Application Firewall challenges or blocks external scanner probes before they reach your application, so a scan of a WAF-protected site reports only the surface the WAF lets through. The scanner is working; so is the WAF. Allowlisting an authorized scanner restores full coverage without weakening defenses against anyone else.
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 on its first pass 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. Suppose 87% of probes return a challenge page: we then 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, which on a heavily protected site is a small fraction of the 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, and what it buys you is coverage: the scanner tests the application itself rather than the edge in front of it.
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 info@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 info@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 info@driftalarm.com and we'll add you to the early-access list and prioritize accordingly.
Frequently Asked Questions
Why does my scan show fewer findings on a WAF-protected site?
Because the probes never reached your application. A WAF in front of your origin returns a challenge page or a block response — usually HTTP 403 or 503 — and that response is all the scanner sees, so those endpoints cannot be tested. Findings reflect only the WAF-bypassable surface. That is your edge defenses working, but it means the scan understates what is actually reachable behind them.
Should I allowlist DriftAlarm's scanner in my WAF?
For most teams, yes. The allowlist rule is scoped to a single dedicated egress IP, so every other source — including attacker traffic — still hits your full rule set. What changes is visibility: you see the application the way someone who got past the edge would. If you only want a perimeter view, staying WAF-limited is a legitimate choice, and the banner keeps that limitation visible.
Does DriftAlarm try to bypass WAFs?
No. We surface WAF blocking so you can see it; we never attempt to evade it. Techniques like JA3 fingerprint randomization, rotating source IPs, and solving JavaScript challenges violate most WAF vendors' terms of service and would erode trust. The supported path to full coverage is customer-driven: allowlist the scanner's dedicated egress IP, and everything else stays blocked as normal.
How do I know if a WAF is limiting my scan results?
The asset detail page shows a banner once more than half of the probed URLs come back as WAF challenges, with the vendor named and the blocked percentage shown; above ninety percent it escalates to the severe state. The banner needs a sample of at least ten probes so a handful of noisy results cannot trigger it. Once allowlisted, it clears after three consecutive low readings.
What WAFs does DriftAlarm detect?
Eight families: Cloudflare, Vercel, Akamai, AWS WAF, Imperva (Incapsula), F5 BIG-IP ASM, Fastly, and Azure App Service. Each is matched on response signature — the CDN name, the status code, and the challenge page title. A generic "WAF" label instead of a vendor name means the response did not match a known pattern; send it over and we will add the signature.
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.