Web application firewalls (WAFs) and rate limits protect production, but they also block security scanners. A scan that was silently blocked looks exactly like a clean scan, which is dangerous.

How it works

The WAF recognises attack payloads and returns 403 pages or challenges, or the rate limiter returns HTTP 429. The scanner records "no vulnerability" for every blocked test. The application behind the WAF is never actually tested.

Why it matters

• False confidence from scans that tested nothing.
• Vulnerabilities in the application stay hidden until the WAF is bypassed.
• Scans that take far longer because of throttling.

Best practices

• Allow-list the scanner's IP address in the WAF for authorised test windows, or scan a non-WAF staging environment.
• Lower the request rate to stay under rate limits.
• Check whether a scan was blocked before trusting the result.
• Remember that a WAF is a safety net, not a fix for the vulnerability.

How Vooki Pro helps

• Detects WAF-protected targets up front and during the scan.
• Shows a "partially blocked by WAF" banner on the scan when blocking occurs.
• Alerts on HTTP 429 rate limiting in both web scans and the API Builder.
• Unified request-rate throttling across web scans, API scans and settings.

Frequently asked questions

Can a WAF make a scan look clean?

Yes. If the WAF blocks test payloads, the scanner sees no vulnerability even when one exists.

Should I allow-list the scanner in the WAF?

For an agreed test window, yes, or scan a staging environment without the WAF to test the application itself.

Related: Scoping a security scan correctly · Verifying security fixes with retesting