Common ASV Scan Errors When Behind Cloudflare

  1. The scan only sees Cloudflare, not your origin server. If Cloudflare is proxying traffic ("orange-clouded") and your origin IP isn't reachable, the ASV's scanner will report on Cloudflare's edge infrastructure instead of your actual server. This can mask real vulnerabilities on your origin and does not satisfy the intent of a PCI ASV scan, which must evaluate the system that is actually processing traffic.
  2. 403 Forbidden or "no response" results. Cloudflare's Web Application Firewall (WAF), Bot Fight Mode, or Security Level settings frequently block or challenge automated scanner traffic, since it looks like malicious bot activity. The scan then comes back with blocked requests rather than real findings, which an ASV cannot mark as a passing scan.
  3. JS challenge or CAPTCHA pages returned instead of real content. If "I'm Under Attack Mode" or a JS/managed challenge is active, the scanner receives a challenge page instead of your site, which can produce a false pass (nothing to find) rather than an accurate result.
  4. 522/524 timeout errors. These indicate Cloudflare could not get a timely response from your origin, often because the origin's firewall only allows Cloudflare's published IP ranges and is rejecting or dropping the ASV's scanning IPs, or because scan traffic volume is triggering rate limiting somewhere in the chain.
  5. SSL/TLS certificate errors when scanning the origin IP directly. If you bypass Cloudflare and scan your origin server's IP address directly, the certificate presented may not match that IP (since the certificate is usually issued for the hostname), producing SSL findings that don't reflect a real-world risk.
  6. Findings that describe Cloudflare's edge instead of your server. Because Cloudflare terminates TLS and proxies HTTP at the edge, some scan findings (TLS cipher suites, HTTP headers, server banners) can reflect Cloudflare's configuration rather than your origin server's, leading to false positives or negatives if the scan isn't scoped correctly.
  7. HSTS flagged as missing or weak, even though it's set correctly. Cloudflare has its own HSTS setting under SSL/TLS > Edge Certificates, separate from whatever your origin server sends. If that setting is off, or its Max-Age, includeSubDomains, or preload options don't match, the scan can report Strict-Transport-Security as missing even when your origin is configured right. This is one of the most common false positives on scans that go through Cloudflare.

How to get an accurate scan:

  1. Disable Cloudflare's proxy for the scan window. The fastest way to get accurate, immediate results is to switch the affected DNS record to "DNS only" (grey-cloud) in Cloudflare for the duration of the scan. This sends the ASV's scanner directly to your origin server, bypassing the WAF/CDN entirely, so there's nothing to allow-list or reconfigure and the results reflect your real server right away. Re-enable the proxy (orange-cloud it again) as soon as the scan finishes.
  2. If you can't take Cloudflare out of the traffic path during the scan (for example, you don't want to lose DDoS protection even briefly), allow-list your ASV's scanning IP ranges in Cloudflare (WAF custom rules or IP Access Rules) instead, and temporarily disable "I'm Under Attack Mode" and aggressive bot/challenge settings during the scan window.
  3. Make sure your origin server's firewall permits both Cloudflare's published IP ranges and your ASV's scanning IPs, so requests aren't dropped and timeouts (522/524) don't occur.
  4. If your ASV needs to scan the origin server directly to satisfy 11.3.2, coordinate the correct hostname/Host header so the origin's SSL certificate validates properly, rather than scanning a bare IP address.
  5. Check the Strict-Transport-Security header your site actually sends. Run curl -sI https://yourdomain.com and look for Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. If Cloudflare's HSTS setting (SSL/TLS > Edge Certificates > HSTS) is enabled and matches that value, the header is already correct, and you should ask your ASV for a false-positive exception instead of making further changes.
  6. Schedule the scan window with your hosting/network team in advance so any temporary DNS, firewall, or WAF changes can be reverted immediately afterward.

Confirm with your ASV which IP address(es) are being scanned before your next quarterly window. If you're not sure how your site is configured behind Cloudflare, reach out to your scanning provider so these issues can be resolved ahead of time rather than causing a failed or inconclusive report.