In March 2025, a two-year grace period quietly ended. PCI DSS 4.0's requirements 6.4.3 and 11.6.1 — both aimed squarely at the JavaScript running on payment pages — shifted from "best practice" to mandatory for every merchant that accepts card payments online. For most e-commerce teams, that means the third-party scripts powering chat widgets, analytics, A/B testing, ad pixels, and payment UI now fall under formal compliance scrutiny for the first time. This matters because these exact scripts are the attack surface behind Magecart-style card-skimming campaigns that have hit British Airways, Ticketmaster, Newegg, and thousands of smaller retailers. Understanding the PCI DSS 4.0 third-party JavaScript requirements — what they cover, what "authorized" and "integrity" actually mean in practice, and how auditors will check for compliance — is now a prerequisite for passing an assessment, not an optional hardening step. Here's what changed and how to respond.
What Are the New PCI DSS 4.0 Third-Party JavaScript Requirements?
Requirement 6.4.3 requires every e-commerce merchant to manage all scripts that load and execute in the consumer's browser on a payment page, with three specific controls: a method to confirm each script is authorized, a method to assure each script's integrity, and a current inventory of every script with a documented business justification for why it's there. This applies whether the script is served from your own domain or pulled in from a third party like a tag manager, chatbot vendor, or marketing pixel — if it runs in the buyer's browser on a page where cardholder data is entered, it's in scope. The PCI Security Standards Council introduced this as a direct response to a shift in attacker behavior: skimming has moved from server-side malware to client-side JavaScript injection, which traditional network firewalls and server hardening never touch. Requirement 6.4.3 became mandatory on March 31, 2025, following the standard's customary phased rollout — it was published as part of PCI DSS v4.0 in March 2022 and listed as a "future-dated" requirement to give merchants time to build tooling.
Why Does PCI DSS Now Regulate Client-Side Scripts Specifically?
The short answer: because that's where the fraud has actually been happening. The client-side script security requirement 6.4.3 exists because the PCI Council's own data, echoed by incident responders at Visa, Mastercard, and firms like RiskIQ and Sansec, shows that the majority of e-commerce card-data theft over the past several years has come from JavaScript-based skimmers rather than compromised servers or databases. A single injected line of code — often smuggled in through a compromised third-party library, an expired domain a script depended on, or a poisoned npm package — can silently copy card numbers, names, and CVVs as a shopper types them into a checkout form, then exfiltrate that data to an attacker-controlled server before the transaction even completes. Server-side controls like network segmentation, WAFs, and encrypted storage do nothing to stop this, because the theft happens entirely inside the customer's browser, outside the merchant's server logs. PCI DSS 4.0 closes that blind spot by making script governance an explicit, auditable control rather than an implicit assumption.
How Do Magecart Attacks Exploit Third-Party JavaScript?
Magecart groups compromise a trusted script — often a widely used third-party tag, chat plugin, or ad library — and modify it to quietly harvest payment form fields before forwarding the data to the checkout process as if nothing happened. The name covers dozens of loosely affiliated threat actors, not one group, and their attacks have proven remarkably durable: the 2018 British Airways breach exposed roughly 380,000 card transactions and led to a £20 million fine from the UK's ICO; the Ticketmaster UK breach the same year, traced to a compromised third-party chatbot script, resulted in a £1.25 million penalty; and Newegg's 2018 incident ran undetected on its checkout page for over a month. More recent research from Sansec and Jscrambler has repeatedly found Magecart-style skimmers active on thousands of live storefronts at any given time, frequently reinfecting sites that removed the malware once but never addressed the underlying lack of script visibility. Magecart attack prevention is precisely what 6.4.3's authorization and integrity controls are designed to force: if every script must be explicitly approved and its integrity continuously verified, an attacker's unauthorized modification gets flagged instead of running silently for weeks.
What Counts as a "Payment Page" Under Requirement 6.4.3?
A payment page is any page delivered to a consumer's browser that is involved in the payment process, which the Council has clarified extends beyond the final "Enter Card Details" screen to any page in the flow where a script could reach cardholder data, including pages that redirect or iframe to a hosted payment page. This broad definition catches merchants off guard because it includes cart pages, pages with embedded payment iframes, and any page a script could traverse the DOM from, even if the visible card field itself sits inside a PCI-compliant iframe from a payment processor. The practical implication is that merchants can't simply declare their checkout "out of scope" because they use a hosted payment field — if third-party scripts execute anywhere near that flow, they need to be inventoried and controlled. Assessors are increasingly asking merchants to map their entire script supply chain for the checkout journey, not just the final payment form, which is a materially larger task than most e-commerce security teams initially scoped for.
What Does Requirement 11.6.1 Add on Top of 6.4.3?
Requirement 11.6.1 requires a change- and tamper-detection mechanism that alerts staff to unauthorized modifications of HTTP headers and payment page content as actually received by the consumer's browser, evaluated at least once every seven days or per a documented targeted risk analysis. Where 6.4.3 is about governing which scripts are allowed to run, 11.6.1 is about continuously watching for the moment that governance is bypassed — the mechanism has to detect changes to the page as rendered client-side, not just changes to source files on the server, since a Magecart injection often happens at the CDN, ad-network, or browser-execution layer rather than in your own codebase. This is a meaningfully different capability than most web application firewalls or server-side file integrity monitoring tools provide, because it requires visibility into what actually executes in a real browser session, including scripts loaded dynamically after the initial page render. Together, 6.4.3 and 11.6.1 form a pair: one control curates and vets the script inventory, the other watches it in real time for e-commerce skimming protection that persists after the initial audit.
When Do Merchants Need to Comply, and What Happens If They Don't?
Both requirements have been mandatory since March 31, 2025, meaning any Qualified Security Assessor conducting a PCI DSS 4.0.1 assessment today will test for them, and merchants without documented controls should expect a finding. Non-compliance doesn't trigger an automatic fine directly from the PCI Council, but it puts merchants in breach of their card brand agreements, which can lead to increased transaction fees, mandatory forensic investigation costs after any breach, and in serious cases, loss of the ability to process card payments altogether — separate from the regulatory fines and civil liability that follow an actual skimming incident, as British Airways and Ticketmaster both learned. Acquiring banks are also tightening their own reviews of Attestations of Compliance, and several have begun requesting evidence of script inventories and integrity monitoring specifically, rather than accepting a checkbox "yes" on the Self-Assessment Questionnaire. Merchants still building this capability should treat it as a live compliance gap, not a future project.
How Safeguard Helps
Safeguard was built for exactly this class of problem: proving control over software you don't fully control. For requirement 6.4.3, Safeguard continuously discovers every script executing on your payment and checkout pages — including scripts loaded dynamically by other scripts — and maps each one to an owner, a purpose, and an authorization record, turning what is usually a manual spreadsheet exercise into a living, audit-ready inventory. Integrity is enforced through continuous verification against known-good baselines, so a tag manager update, a compromised CDN, or a tampered third-party library gets flagged before it reaches a shopper's browser, not after a chargeback report surfaces it. On the 11.6.1 side, Safeguard's browser-level monitoring evaluates rendered payment pages on a schedule that satisfies the standard's detection cadence, generating the alerting and evidence trail assessors expect to see, along with the historical change logs needed to demonstrate ongoing monitoring rather than a one-time review. For security and compliance teams facing their first 4.0.1 assessment cycle, that combination — script inventory, integrity assurance, and tamper detection in one system — closes the gap between what the standard requires and what most teams currently have visibility into, without adding another disconnected tool to the checkout stack.