Third-party scripts and PCI DSS 4.0: what ecommerce stores must monitor

PCI DSS 4.0 requirements 6.4.3 and 11.6.1 became mandatory on March 31, 2025. They address one of the most persistent threats in ecommerce: malicious JavaScript injected into payment pages to steal card data. These requirements exist because Magecart-style attacks compromised millions of card numbers while traditional security controls failed to detect them.

The requirements are specific. Every script on a payment page must be inventoried and authorized. Changes to page content or HTTP headers must be detected automatically. The monitoring must happen from the perspective of an actual browser, not a server. If your store processes card payments and you have not addressed these requirements, you are out of compliance.

The attacks that motivated these requirements

Magecart is the collective name for groups that inject JavaScript skimmers into ecommerce payment pages. The attack pattern has been consistent for a decade: find a way to modify a payment page, insert a small script, collect card numbers and CVVs as customers type them and exfiltrate the data to an attacker-controlled server.

The British Airways breach in 2018 compromised approximately 380,000 payment cards over 22 days. Attackers modified a JavaScript file served from the British Airways domain. The script was 22 lines. It captured card details from the checkout form and sent them to a domain registered to look like a legitimate payment processor. British Airways received a 20 million GBP fine from the UK ICO.

Ticketmaster was compromised in 2018 through a third-party customer support chatbot script. The chat widget loaded on the payment page and was modified to exfiltrate card data. Ticketmaster did not detect the compromise for several months. The incident exposed around 40,000 customer payment records.

Newegg suffered a similar attack in 2018. Attackers registered a domain designed to look like a Newegg subdomain, hosted a skimming script there and injected a single line of code into the Newegg checkout page to load it. The attack ran for over a month.

These are the large disclosed cases. Security researchers estimate that thousands of smaller stores are compromised at any given time, with attacks often running undetected for months because the payment page continues to function normally. Our guide on Magecart attack prevention for ecommerce covers detection and defense strategies in depth. Our guide on payment page security covers the full range of threats and defenses beyond script management.

Requirement 6.4.3: script inventory and authorization

Requirement 6.4.3 covers all scripts loaded and executed on payment pages. It requires three things:

• A method to confirm that each payment page script is authorized.
• Assurance of the integrity of each script.
• A written inventory of all scripts with justification for why each is necessary.

"Payment page" is interpreted broadly. It includes the checkout page, any page where card data is entered or processed and any page that could influence the payment flow. For most ecommerce stores this means at minimum the cart page, the checkout page and any page containing a payment widget or iframe.

What counts as a payment page script

Every piece of JavaScript that executes on the payment page is in scope, regardless of whether it has anything to do with payment processing. This includes:

• Payment processor SDKs: Stripe.js, Braintree client, Adyen Web Components, PayPal JS SDK.
• Analytics: Google Analytics, Adobe Analytics, Heap, Amplitude.
• Session recording: Hotjar, FullStory, Microsoft Clarity.
• Marketing pixels: Meta Pixel, TikTok Pixel, Google Ads remarketing tag.
• Chat and support widgets: Intercom, Zendesk, Drift.
• Fraud detection: Signifyd, Kount, NoFraud.
• A/B testing: Optimizely, VWO, Google Optimize successors.
• Your own application JavaScript: theme code, checkout customizations, custom event tracking.

Most stores are surprised by the count. A typical mid-market ecommerce checkout page loads between 15 and 40 scripts. Many were added over time by different teams, agencies or app vendors with no central tracking.

Building the inventory

The inventory must document each script with its source URL or hash, its purpose and written justification for its presence on the payment page. The process starts with enumeration. Load your checkout page in a browser, open the developer tools Network tab filtered to JS, and capture every script that loads. Repeat in an incognito window to avoid cached state.

For each script, determine whether it actually needs to be on the payment page. Analytics scripts that track purchase completions can often be moved to a post-purchase confirmation page. Marketing pixels rarely need to fire during the checkout process itself. Removing unnecessary scripts reduces risk and simplifies compliance.

Integrity verification

Two mechanisms satisfy the integrity requirement: Subresource Integrity and Content Security Policy.

Subresource Integrity works for scripts loaded from external sources. You add a cryptographic hash to the script tag. If the script's content changes, the hash no longer matches and the browser refuses to execute it. The W3C SRI specification is well-supported across modern browsers.

The limitation of SRI is that it breaks whenever the script provider updates their script. Many third-party vendors update scripts frequently and do not publish hash values. SRI is practical for pinned, infrequently-changed scripts but impractical as a sole mechanism for all third-party scripts.

Content Security Policy provides a broader control layer. A properly configured CSP for a payment page specifies exactly which origins are permitted to serve scripts. Any script from an unlisted origin is blocked by the browser. CSP does not verify script content integrity, but it prevents entirely new unauthorized script sources from loading.

Combining CSP with SRI for specific high-risk scripts gives the strongest coverage. The PCI SSC guidance acknowledges that a combination of controls can be used to satisfy the integrity requirement.

Requirement 11.6.1: tamper detection

Requirement 11.6.1 is the monitoring counterpart to 6.4.3's inventory. Where 6.4.3 establishes what should be on the payment page, 11.6.1 requires detection when the actual state deviates from the authorized state.

The requirement specifies:

• A change and tamper detection mechanism must be deployed to alert personnel to unauthorized modification of HTTP headers and content on payment pages as received by the consumer browser.
• The mechanism must evaluate changes at least once every seven days, or at a frequency defined by a targeted risk analysis.

The critical phrase is "as received by the consumer browser." This rules out server-side monitoring. A server-side check confirms what your server is sending. It does not detect changes introduced by CDN manipulation, browser extensions injected at the network level, compromised third-party scripts or DOM modifications made by other scripts after page load.

Compliant monitoring requires a browser-based agent, typically a headless browser, that loads your payment page the way a real customer would, captures the full set of scripts and headers, and compares them against a known-good baseline.

What to monitor

The requirement covers both HTTP headers and page content. For headers, the primary concern is security-related headers that could affect payment page integrity: Content Security Policy, X-Frame-Options, Strict-Transport-Security. A change to your CSP header could weaken controls you rely on for script authorization.

For page content, the monitoring should detect:

• New scripts appearing that were not in the authorized inventory.
• Changes to the content or hash of existing authorized scripts.
• Changes to script source URLs, including subdomain variations designed to look legitimate.
• New inline script blocks injected into the page HTML.
• Changes to form action attributes on payment forms.

The seven-day monitoring cadence is a minimum. Organizations with higher risk profiles or that have experienced previous incidents should run checks more frequently. Daily or continuous monitoring is achievable and provides substantially better detection windows.

Platform-specific guidance

Shopify

Shopify's core checkout is hosted on Shopify's infrastructure and is certified PCI compliant at the platform level. However, Shopify merchants have several vectors through which unauthorized scripts can appear on payment pages.

Theme code modifications can add scripts. Shopify apps inject scripts through the ScriptTag API or through theme app extensions. Checkout customizations via Shopify's checkout extensibility framework can introduce additional JavaScript. Each of these is the merchant's responsibility to track.

Shopify's built-in CSP for checkout pages restricts many script sources by default, but merchants who use Shopify Plus checkout customizations need to verify that their customizations do not introduce unnecessary script loads. The Shopify app review process does not constitute PCI authorization of app scripts.

WooCommerce

WooCommerce on WordPress gives merchants full control of the checkout page and the highest exposure. The WordPress plugin ecosystem means scripts from dozens of plugins may be enqueued on the checkout page. Plugins installed for non-checkout purposes, contact forms, SEO tools, social sharing widgets, may still inject scripts on every page including checkout.

WooCommerce merchants should use a plugin that controls script loading on a per-page basis, allowing non-payment scripts to be suppressed specifically on checkout. Several performance optimization plugins provide this capability as a side effect.

Implementing CSP on WordPress requires either a dedicated security plugin or server-level configuration. WooCommerce has no built-in CSP. This is one of the reasons WooCommerce stores represent a disproportionate share of Magecart victims.

Magento and Adobe Commerce

Magento 2 and Adobe Commerce include built-in Content Security Policy support, introduced in version 2.3.5. The implementation uses a developer-mode CSP that reports violations without blocking, and a production-mode CSP that blocks unauthorized resources.

Many Magento merchants have not enabled production-mode CSP because third-party extensions frequently make CSP violations that break functionality. Getting to a clean production CSP requires auditing every extension and whitelisting legitimate sources explicitly.

Magento has historically been a primary Magecart target due to its large install base and the prevalence of outdated installations with unpatched vulnerabilities. Requirement 11.6.1 monitoring is particularly important for Magento stores.

Implementing compliance

A practical path to compliance for requirements 6.4.3 and 11.6.1 involves four steps.

First, enumerate and document. Load your payment pages in a browser and capture every script, its source and its purpose. Remove scripts that do not need to be present. Create the written inventory the standard requires.

Second, implement authorization controls. Deploy a Content Security Policy for your payment pages that permits only the script sources in your inventory. Add SRI hashes for scripts where the provider supports pinning.

Third, establish a baseline. Capture the authorized state of your payment pages including script hashes, script sources and HTTP headers. This is the baseline against which future checks will compare.

Fourth, automate monitoring. Deploy browser-based monitoring that checks your payment pages at least weekly against the baseline and alerts on deviations. The alert must reach someone who can investigate and respond.

The cost of getting this wrong

PCI DSS compliance is enforced by the payment card brands through acquiring banks. A store found non-compliant faces monthly fines from $5,000 to $100,000 depending on merchant level and the severity of findings.

If a breach occurs while a store is non-compliant with 6.4.3 or 11.6.1, the financial consequences are substantially worse. Forensic investigation costs typically run $50,000 to $500,000. Card replacement costs, which acquirers can pass to the merchant, run $3 to $10 per compromised card. Liability for fraudulent transactions can reach into the millions.

Beyond the direct costs, a card data breach triggers notification obligations under state breach notification laws, potential FTC scrutiny and reputational damage that affects conversion rates for months afterward. Security researchers consistently find that customer trust takes 12 to 18 months to recover after a publicly disclosed breach.

Requirements 6.4.3 and 11.6.1 are not bureaucratic checkboxes. They are the direct response to a well-documented attack pattern that has cost ecommerce merchants and card issuers billions of dollars. The stores most at risk are those that have never audited what JavaScript runs on their checkout pages. The answer is usually more than they think. For merchants under SAQ A-EP or SAQ D, the related penetration testing requirements add another layer of mandatory validation.

Frequently asked questions

How many scripts does a typical ecommerce checkout page load?

A typical mid-market ecommerce checkout page loads between 15 and 40 scripts. These include payment processor SDKs, analytics, marketing pixels, chat widgets, fraud detection and application code.

What is the difference between PCI DSS requirements 6.4.3 and 11.6.1?

Requirement 6.4.3 requires an inventory and authorization of every script on payment pages. Requirement 11.6.1 requires automated detection of unauthorized changes to payment page content and HTTP headers at least every seven days.

Does server-side monitoring satisfy PCI DSS 11.6.1?

No. The requirement specifies monitoring as received by the consumer browser. Server-side checks do not detect changes introduced by CDN manipulation, compromised third-party scripts or DOM modifications after page load.

How do SRI and CSP work together for PCI DSS compliance?

CSP prevents scripts from unauthorized domains from loading. SRI verifies that scripts from authorized domains have not been tampered with. Together they close both the unauthorized source and modified content attack vectors.