PCI Compliant Checkout: Hosted, iFrame or API? Which SAQ
Hosted page, iFrame or API? See which SAQ each PCI compliant checkout option triggers, which scans and scripts you must cover, and how to choose
Cloudflare’s protective layers; WAF, DDoS mitigation, rate limiting; are powerful security tools. They are also exactly the kind of active protection system that PCI DSS Section 5.6 says must not interfere with your quarterly ASV scans.
Here is how to resolve that tension without compromising either compliance or security. PCI DSS 4.0.1ASV ScanningCloudflare WAFQuarterly Compliance
PCI DSS Section 5.6 (ASV Scan Interference) is unambiguous: every ASV scan must be validated to confirm it has not been blocked or filtered by an active protection system.
If blocking is detected, the ASV must resolve the scan as inconclusive per Section 7.6; which is a compliance failure, not a workaround.
If scan interference is recorded in the report, the scan automatically fails. A failed scan cannot be disputed after the fact simply by claiming no active blocking was in place; it must be prevented before the scan runs.
The standard distinguishes two types of protective systems:
Cloudflare sits between the internet and your origin server as a reverse proxy. This creates two distinct problems for ASV scanning.
When your ASV scans a domain that resolves to Cloudflare’s edge network, it is scanning Cloudflare — not your actual server. Vulnerabilities on your origin infrastructure will not be found. PCI DSS is explicit that the scan must cover all externally accessible systems within the cardholder data environment (CDE), so scanning only the proxy does not satisfy the requirement.
Scanning yourdomain.com (which resolves to Cloudflare IPs) is not the same as scanning your web server. Your ASV report must cover the origin server, not the proxy in front of it.
Cloudflare operates several protection mechanisms that fall squarely into the “active protection system” category described in PCI DSS Section 5.6:
Even with ASV IP ranges whitelisted, Cloudflare’s autonomous DDoS detection can override explicit allow rules during the scanner’s validation phase — a known issue documented in the Cloudflare community forums.
This is not a configuration error; it is the system doing exactly what it was designed to do.
| IPS/IDS that only alerts | No interference — passive, does not modify traffic flow |
| WAF blocking SQL injection, allowing clean traffic from same IP | No interference — static, consistent behaviour |
| Rate limiting that blocks IP after threshold | Interference — dynamic behaviour change based on traffic pattern |
| DDoS protection blocking scanner IP range | Interference — reactive, pattern-based IP block |
| Cloudflare WAF challenge page for scan traffic | Interference — dynamically modifies response for scanning behaviour |
| Firewall always blocking specific closed ports | No interference — static, rule-based, consistent |
| Cloudflare bot score challenge | Interference — dynamic scoring model, modifies based on behaviour |
There are two approaches to achieving a clean, interference-free ASV scan when Cloudflare is in use. Which strategy you choose depends on your infrastructure and risk tolerance.
Configure Cloudflare to bypass WAF, rate limiting, DDoS mitigation, and bot management for your ASV’s IP ranges. Scanning proceeds through Cloudflare but without interference. The scan assesses what Cloudflare exposes on the origin’s behalf.
Temporarily expose the origin server’s IP to the ASV scanner, bypassing Cloudflare entirely. Provides the most thorough scan but temporarily removes the proxy layer. Must be tightly controlled and time-limited.
Most organisations use Strategy A for convenience. However, if your CDE includes backend services not served through Cloudflare, those must be scanned directly regardless. Strategy B is technically more complete but introduces a temporary exposure window. Both require documentation for your QSA.
Your ASV is required to provide the complete list of IP ranges from which their scanners operate. These are published by most major ASVs. Examples include Qualys, Trustwave, Rapid7, SecurityMetrics, and Nabu. Do not proceed until you have confirmed and documented the current IP list directly from your ASV; these ranges change periodically.
Dashboard → Security → Tools → IP Access Rules Action: Allow Value: [ASV IP range, e.g. 38.123.140.0/25] Zone: Apply to all websites in account (or specific zone)
This step grants baseline access. However, it is not sufficient on its own; Cloudflare's autonomous systems (WAF, DDoS, bot management) can still trigger over and above IP allow rules.
Dashboard → Security → WAF → Custom Rules → Create rule Field: IP Source Address Operator: is in Value: [ASV IP ranges] Action: Skip ☑ All remaining custom rules ☑ Super Bot Fight Mode (if enabled) ☑ WAF managed rules ☑ Rate limiting rules Save rule; place it as the first rule in priority order.
The skip rule must be evaluated before any blocking rule fires. If it sits below a rate-limiting rule in the execution order, the block fires first, and the skip is never reached.Drag the bypass rule to the top of your custom rules list.
Dashboard → Security → DDoS → HTTP DDoS Attack Protection Add Override: Expression: ip.src in {ASV IP ranges} Sensitivity: Essentially Off Action: Allow
This step is critical and frequently missed. Even with a WAF skip rule in place, Cloudflare's DDoS autonomous system operates at a lower layer and can block scan traffic independently. Setting sensitivity to "Essentially Off" for the ASV IP range disables that dynamic response.
Dashboard → Caching → Cache Rules Match: Hostname is [your domain] Action: Bypass cache
Cloudflare caching can cause the scanner to receive stale, cached responses that do not reflect the actual state of your origin server. This creates false negatives; vulnerabilities present on the origin may not be detected if the scanner receives a cached, clean response instead.
Run a test request from your ASV's IP range before the formal scan window and check the Firewall Activity Log in the Cloudflare dashboard. If any events are logged as "Block" or "Challenge" for the ASV IP, the configuration is incomplete. Investigate and resolve before scheduling the formal scan.
Cloudflare's Activity Log is your best diagnostic tool. Filter by the ASV IP range and confirm every request shows "Allow" action. A single "Block" or "Challenge" event means the scan will report interference.
If interference is detected despite configuration steps, PCI DSS Section 7.6 governs resolution. The ASV marks the scan inconclusive. The merchant must then either:
Exception requests are time-consuming, require QSA involvement, and may not be accepted. Resolving the Cloudflare configuration properly before the scan window is the only reliable path to a clean quarterly result.
This article is based on PCI DSS ASV Program Guide requirements (Section 5.6 and 7.6) and Cloudflare's published PCI scanning documentation at developers.cloudflare.com/fundamentals/security/pci-scans. Configurations shown reflect the Cloudflare dashboard as of 2025.
Always validate configuration steps against current Cloudflare documentation before your scan window, as interface paths change with product updates.
Yes. Cloudflare's security features, such as the Web Application Firewall (WAF), rate limiting, DDoS protection, and Bot Management, can block or challenge ASV scan traffic. If these protections interfere with the scan, the result may be marked as inconclusive or failed under PCI DSS requirements.
Yes. Before running a PCI ASV scan, you should obtain your ASV provider's IP ranges and create allow or bypass rules in Cloudflare. This helps prevent WAF, rate limiting, and other security features from interfering with legitimate scan traffic.
Your PCI ASV scan must cover all internet-facing systems within the PCI DSS scope. If Cloudflare acts as a reverse proxy, scanning only the Cloudflare edge may not identify vulnerabilities on your origin server. Depending on your environment, your ASV or QSA may require the origin server to be scanned directly.
PCI DSS 4.0.1 (current as of 2026) maintains the quarterly external scan requirement for applicable merchants and service providers. Key changes relevant to ASV scanning include updated requirements around multi-factor authentication for CDE access (Requirement 8) and expanded scope definitions under the network security controls section (Requirement 1), which can increase the number of IPs that fall within scan scope. Review your CDE boundary before purchasing a pricing tier to avoid scope underestimation.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.