PCI DSS v4.0.1: New Rules Target Checkout Scripts to Stop Skimmers

When a shopper enters their card number on a modern checkout page, their browser is executing far more than the merchant's own code. Analytics tags, tag managers, support widgets, and embedded payment iframes typically add dozens of third-party scripts to the page, any one of which can be quietly weaponized into a skimmer. This is the operational model behind Magecart, and the damage is no longer hypothetical: threat intelligence firm Sansec has tracked more than 100,000 websites compromised by web skimming and supply-chain attacks, while the 2018 British Airways incident exposed roughly 380,000 payment card transactions and triggered a fine that started at £183 million. In nearly every case, the malicious payload arrived through a vendor script the merchant had already approved, with attackers compromising a third-party provider so the skimmer rides in on a trusted tag that no one thinks to re-examine. Readers can verify their own exposure with a free email breach checker or scan their site headers using our SSL/TLS checker.

PCI DSS v4.0.1 directly addresses this blind spot through two requirements that are now fully in force. Requirement 6.4.3 mandates that every payment-page script be inventoried, explicitly authorized, and proven to maintain its integrity, while Requirement 11.6.1 requires tamper detection on page content and HTTP headers as the browser actually receives them. Manual compliance is impractical at scale: Reflectiz telemetry shows that roughly 30% of scripts on a typical payment page change within any two-week window, meaning static hash checks quickly go stale. The differences between a script's file signature and its runtime behavior are exactly what a skimmer exploits.

An independent review by Integrity360 Europe, a PCI Qualified Security Assessor and member of the PCI SSC Global Executive Assessor Roundtable, evaluated the Reflectiz PCI DSS Platform against both controls and concluded it can effectively support compliance. The assessment highlighted three capabilities: behavioral monitoring that catches a script the moment it reaches for card data even after a silent vendor-side swap, an agentless deployment model that requires no code changes or page snippets, and one-click QSA-ready audit evidence per page. Separately, since January 2025, merchants filing SAQ A can only drop 6.4.3 and 11.6.1 if they can demonstrate their site is not susceptible to script attacks. Full redirect to a processor-hosted page generally qualifies; embedding a payment iframe does not, since a malicious parent-page script can still hijack input before it reaches the secure frame. PCI SSC FAQ #1588 points straight back to the same controls for merchants seeking the exemption, underscoring that iframe-based checkouts must prove script-driven skimming is impossible. As you tighten your payment surface, a quick privacy checkup can help flag unrelated browser-level exposures that may compound the risk.