Deployment: Invicti Platform on-demand, Invicti Platform on-premises
Web Application Firewall (WAF) detected
This document explains the WAF Detected alert, why WAF affects scan accuracy, and recommended actions to get reliable results.
What does it mean
The scanner has detected that a Web Application Firewall (WAF) or security proxy is positioned in front of the target web application. It identifies the WAF vendor where possible, based on signals in the HTTP responses, such as specific headers, cookie names, response status codes, and block page content.
The scanner currently recognizes over 100 WAF products, including Cloudflare, F5 BIG-IP ASM, AWS WAF, Imperva Incapsula, Barracuda, ModSecurity, Citrix NetScaler, Fortinet FortiWeb, Sucuri, Wordfence, SonicWall, and many others.
Information is visible in the Scan activity section of the Scan summary page.
How does the scanner detect it
During the initial phase of a scan, the scanner sends a small set of probe requests to the target, including requests containing common attack patterns such as path traversal, XSS, SQL injection, and an invalid HTTP method.
Why does this matter
A WAF detected during scanning is a strong indicator that the scan results may be incomplete or misleading. This isn't a vulnerability in itself, but it's an important operational finding that affects the reliability of the entire scan.
Why we recommend scanning without a WAF
Scanning through a WAF produces results that reflect what the WAF allows through, not the true security posture of the underlying application. Specifically:
-
False negatives - Attack probes blocked by the WAF never reach the application. Vulnerabilities that exist in the app won't be detected because the scanner never receives a genuine application response to those payloads.
-
Distorted responses - When the WAF blocks a request, it returns its own error page rather than the application's response. The scanner can't distinguish "the application handles this safely" from "the WAF intercepted this before it reached the application."
-
Incomplete crawling - WAFs can block or throttle requests that look automated, causing the scanner to miss pages, parameters, and functionality entirely.
-
Incorrect severity assessments - Vulnerabilities may appear less severe or exploitable than they're because the WAF dampens the visible impact during testing.
-
Rate limiting and IP blocking - Many WAFs throttle or ban the scanner's IP mid-scan, resulting in incomplete or aborted scans.
The goal of a vulnerability scan is to assess the security of the application itself. A WAF is a compensating control, useful in production, but it shouldn't be relied on to mask vulnerabilities that remain in the underlying code and configuration.
Recommended approach
Where possible, configure your scan to bypass the WAF entirely. Use one of the following methods:
- Scanning directly against the origin server IP, bypassing DNS (and therefore the WAF/CDN).
- Trustlisting the scanner IP in the WAF so all scanner traffic is allowed through unconditionally.
- Scanning from within the internal network, behind the WAF.
- Using a dedicated staging or pre-production environment that doesn't sit behind the WAF.
If bypassing the WAF isn't possible, refer to the Consequences of scanning without trustlisting document for more information.
Need help?
Invicti Support team is ready to provide you with technical help. Go to Help Center