PCI DSS compliance

The Payment Card Industry Data Security Standard (PCI DSS) applies to any organization that stores, processes, or transmits payment card data. When your site or application runs behind Cloudflare, several PCI DSS requirements apply to how Cloudflare handles your traffic — and some require explicit configuration on your zone.

This guide walks through the Cloudflare configuration steps required for PCI DSS compliance, explains how Cloudflare interacts with PCI Approved Scanning Vendor (ASV) scans, and lists known scanner false positives.

Cloudflare is certified as a Level 1 PCI DSS Service Provider — the highest certification level. You can obtain Cloudflare's current Attestation of Compliance (AOC) from the Cloudflare Trust Hub ↗.

Steps 1 and 2 are required for PCI DSS compliance. Step 3 is Cloudflare's recommendation for a stronger configuration but is not mandated by PCI DSS v4.0, which sets TLS 1.2 as the minimum. A PCI scan checks each layer independently — completing only Steps 1 and 2 is sufficient to meet the standard.

PCI DSS requirement 4.2.1 mandates strong cryptography for cardholder data in transit, with TLS 1.2 as the minimum acceptable version. TLS 1.0 and TLS 1.1 are not considered strong cryptography under PCI DSS.

1. In the Cloudflare dashboard, go to SSL/TLS > Edge Certificates.

   Go to Edge Certificates ↗

2. For Minimum TLS Version, select TLS 1.2 or higher.

Refer to Minimum TLS Version for API and Terraform options.

PCI DSS prohibits weak and deprecated cipher algorithms. You must restrict your zone to the PCI DSS-approved cipher list.

Follow the steps in Customize cipher suites (dashboard) and select the cipher suites from the PCI DSS profile listed in Compliance standards. Alternatively, use the API:

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/ciphers" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"value": [
				"ECDHE-ECDSA-AES128-GCM-SHA256",
				"ECDHE-RSA-AES128-GCM-SHA256",
				"ECDHE-ECDSA-AES256-GCM-SHA384",
				"ECDHE-RSA-AES256-GCM-SHA384",
				"ECDHE-ECDSA-CHACHA20-POLY1305",
				"ECDHE-RSA-CHACHA20-POLY1305"
		]
	}'

TLS 1.3 provides stronger security guarantees than TLS 1.2, eliminates several legacy handshake patterns, and is recommended alongside TLS 1.2 for a stronger, future-proof configuration. It is not required for PCI DSS compliance, which mandates TLS 1.2 as the minimum.

1. In the Cloudflare dashboard, go to SSL/TLS > Edge Certificates.

   Go to Edge Certificates ↗

2. Enable TLS 1.3.

Refer to TLS 1.3 for API and Terraform options.

After applying all settings, confirm that non-compliant connections are rejected.

Online TLS scanners give you an external view of your configuration — the same perspective a PCI ASV scan sees. Two commonly used options are:

• SSL Labs Server Test ↗ — enter your domain and review the report. Check for Protocol support (TLS 1.2 and 1.3 only), Cipher strength (no weak or deprecated suites), and an overall grade of A or A+.
• SSL Shopper SSL Checker ↗ — validates your certificate chain and TLS configuration from an external vantage point.

openssl s_client lets you test specific TLS versions from the command line. Connections using TLS 1.0 or TLS 1.1 should fail:

# Should fail — TLS 1.0 rejected
openssl s_client -connect example.com:443 -tls1

# Should fail — TLS 1.1 rejected
openssl s_client -connect example.com:443 -tls1_1

A rejected connection returns an error such as:

4087F5C1E27F0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

To confirm which cipher suite is negotiated over TLS 1.2:

openssl s_client -connect example.com:443 -tls1_2 2>/dev/null | grep -E "Protocol|Cipher"

The output should show a cipher from the PCI DSS-approved list — for example ECDHE-RSA-AES128-GCM-SHA256.

To confirm TLS 1.0 and TLS 1.1 are rejected:

# Should fail — TLS 1.0 rejected
curl https://example.com --tls-max 1.0 -svo /dev/null

# Should fail — TLS 1.1 rejected
curl https://example.com --tls-max 1.1 -svo /dev/null

A rejected connection returns an error such as:

* error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert

On the Edge Certificates page, select View current ciphers to see the cipher suites configured on your zone.

It is not possible to configure minimum TLS version or cipher suites for *.pages.dev hostnames. These settings only apply to zones you control in the Cloudflare dashboard.

For payment pages hosted on a Pages project, use a custom domain attached to a zone you control. Zone-level TLS and cipher suite settings apply to traffic served through that custom domain.

PCI DSS v4.0 introduced two requirements for scripts running in the consumer's browser on payment pages:

Refer to Client-side security and PCI DSS compliance for setup guidance.

PCI DSS requires quarterly vulnerability scans by an Approved Scanning Vendor (ASV). When your domain is proxied through Cloudflare, ASV scanners interact with Cloudflare's edge network rather than your origin server directly. Several behaviors commonly arise.

Some ASV tools report a TCP Source Port Pass Firewall finding against Cloudflare-proxied IP addresses. This is a false positive caused by how source port selection works in Cloudflare's reverse proxy infrastructure, not a vulnerability in your environment.

If your QSA or scanning tool flags this finding, provide:

• Cloudflare's current Attestation of Compliance (AOC) ↗
• Documentation that your domain is proxied through Cloudflare as a PCI DSS Level 1 Service Provider

Your QSA can treat this as a compensating control or documented exception based on Cloudflare's shared responsibility boundary.

ASV scanners send attack-pattern traffic — SQL injection probes, XSS payloads, vulnerability fingerprinting — to test your application. Cloudflare's WAF blocks many of these probes, which is correct WAF behavior, but it can prevent the scanner from completing its assessment.

To allow a scan without disabling your WAF:

1. Obtain the source IP ranges used by your ASV vendor.
2. Create a WAF custom rule that skips managed ruleset matching for those IP ranges, scoped to your scan maintenance window.
3. Remove or disable the rule immediately after the scan completes.

Cloudflare's WAF blocking scanner probes is not a compliance failure — a correctly configured WAF mitigating attack patterns is itself a PCI DSS control (requirement 6.4.1).

Cloudflare proxies a defined set of HTTP and HTTPS ports. For ports outside that list, Cloudflare's anycast network may cause those ports to appear open at the TCP layer even though they are not proxied — the TCP connection is accepted at the edge but HTTP/HTTPS requests are blocked at the application layer before reaching your origin.

If an ASV scan targets non-proxied ports, findings for those ports reflect Cloudflare's edge behavior rather than your origin. Configure your scan to target the ports your application actually serves on, and provide your QSA with the network ports reference to document the expected behavior.

Cloudflare applies these mitigations by default across all proxied zones. No configuration is needed.

Cloudflare does not support:

• Header compression in TLS
• Header compression in SPDY 3.1
• RC4
• SSL 3.0
• Renegotiation with clients
• DHE cipher suites
• Export-grade ciphers

Cloudflare mitigates:

• CRIME
• BREACH
• POODLE
• RC4 cryptographic weaknesses
• SSL renegotiation attacks
• Protocol downgrade attacks
• FREAK
• LogJam
• Sweet32 — 3DES is disabled for TLS 1.1 and 1.2. For TLS 1.0, Cloudflare rotates session keys before the 32 GB threshold required for a successful attack

All Cloudflare servers are patched against Heartbleed, Lucky Thirteen, and CCS injection vulnerability.

Security scans that report Return of Bleichenbacher's Oracle Threat (ROBOT) against a Cloudflare-proxied domain are false positives. Cloudflare validates RSA PKCS#1 v1.5 padding in real time and substitutes a random session key if padding is incorrect, eliminating any exploitable oracle.

If a scanner flags Sweet32, verify that TLS 1.0 is disabled on your zone. Refer to Set minimum TLS version to 1.2 for steps. With TLS 1.0 disabled, the 3DES cipher suites where Sweet32 applies are not in use and the finding does not apply to your environment.

Cloudflare sets the _cfuvid cookie on some zones for rate limiting. When a scanner accesses your site over HTTP, it may report this cookie as missing the Secure attribute. On HTTPS connections, the Secure flag is set correctly — this is a scanner methodology artifact from testing HTTP rather than HTTPS.

To prevent this finding: ensure your zone redirects all HTTP traffic to HTTPS before scanning, and configure your ASV to scan HTTPS endpoints. Refer to Always Use HTTPS for setup steps.