PCI DSS 4.0 for ecommerce: requirements 6.4.3 and 11.6.1 explained

What these requirements mean

PCI DSS 4.0 introduced two requirements that fundamentally change how ecommerce stores must manage payment pages. Requirements 6.4.3 and 11.6.1 became mandatory on March 31, 2025. They affect every store processing card payments, regardless of size, platform or SAQ type.

In plain terms: 6.4.3 says you must know every script on your payment pages and prove each one belongs there. 11.6.1 says you must detect when anything changes.

These requirements target Magecart-style attacks where malicious JavaScript is injected into payment pages to skim credit card data. The PCI Security Standards Council recognized that traditional network-level security does not protect against client-side script attacks.

Requirement 6.4.3: script inventory and authorization

The exact PCI DSS 4.0 text for requirement 6.4.3:

All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: a method is implemented to confirm that each script is authorized; the integrity of each script is assured; an inventory of all scripts is maintained with written justification as to why each is necessary.

This breaks into three obligations:

What a typical checkout looks like

A typical ecommerce checkout loads scripts from multiple sources: payment processor (Stripe, Braintree, Adyen), analytics (Google Analytics, Hotjar), marketing pixels (Meta, Google Ads), session replay, fraud detection and your own application code.

Most stores find 15-30 scripts on a single checkout page, many added by different teams or plugins over time with no central oversight. Requirement 6.4.3 forces you to answer: what is each one, who authorized it and why is it on the payment page?

Requirement 11.6.1: tamper detection

The exact PCI DSS 4.0 text for requirement 11.6.1:

A change- and tamper-detection mechanism is deployed as follows: to alert personnel to unauthorized modification (including indicators of compromise, changes, additions and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser; the mechanism is configured to evaluate the received HTTP header and payment page at least once every seven days, or periodically at the frequency defined in the entity's targeted risk analysis.

Key phrase: “as received by the consumer browser.” Server-side monitoring alone is not sufficient. You must evaluate the page as a real user sees it, after all client-side JavaScript has executed, after all third-party scripts have loaded.

The mechanism must detect:

• A new script appearing that was not previously authorized
• An existing script's content changing (hash mismatch)
• HTTP response headers changing (CSP modifications, missing security headers)
• Script source changes (loading from a different domain)
• Hidden iframes, obfuscated code or other supply chain attack indicators

Why these requirements exist: Magecart attacks

Magecart attacks have been one of the most damaging threats to ecommerce for over a decade. The attack is straightforward: inject a small JavaScript snippet into a payment page that captures card numbers, CVVs and billing addresses as customers type them.

The injected script sends stolen data to an attacker-controlled server while the payment page looks and functions normally. These attacks run undetected for months.

Ticketmaster is especially instructive: the compromise came through a third-party customer support chat widget (Inbenta). Ticketmaster did not modify their own code. A script they trusted was compromised upstream. This is exactly the scenario SRI and CSP prevent.

Who is affected: SAQ types and scope

Your SAQ type determines your specific obligations:

Important: Visa's March 2025 FAQ clarified that even SAQ-A merchants must ensure no scripts on their site can interfere with the redirect to the payment provider. The scope extends beyond the payment page itself to any page that “could influence the payment transaction.” This includes your cart page, order review page and any page that triggers the redirect to hosted payment pages.

Content Security Policy implementation

Content Security Policy (CSP) is the primary mechanism for satisfying 6.4.3's authorization requirement. CSP is an HTTP response header that tells the browser which script sources are allowed to execute.

Starting with report-only mode

Never deploy CSP in enforcement mode on a production checkout without testing first. Use Content-Security-Policy-Report-Only to discover which scripts load without breaking anything:

Content-Security-Policy-Report-Only:
  script-src 'self'
    https://js.stripe.com
    https://www.googletagmanager.com
    https://www.google-analytics.com;
  report-uri /csp-report

Run report-only mode for at least two weeks. Review violation reports. Add legitimate sources to the policy. Once violations are only from scripts you want blocked, switch to enforcement:

Content-Security-Policy:
  script-src 'self'
    https://js.stripe.com
    https://www.googletagmanager.com
    https://www.google-analytics.com;
  report-uri /csp-report

CSP pitfalls for ecommerce

• Inline scripts. Many ecommerce platforms use inline <script> tags. CSP blocks these by default. Use nonces ('nonce-abc123') or hashes rather than 'unsafe-inline', which defeats the purpose of CSP.
• Tag managers. Google Tag Manager dynamically injects scripts, making CSP harder. Consider server-side tagging or moving GTM off payment pages entirely.
• Dynamic script loading. A/B testing tools and personalization engines load scripts dynamically. Each loaded domain must be in your CSP.

Subresource Integrity implementation

Subresource Integrity (SRI) satisfies 6.4.3's integrity verification requirement. SRI adds a cryptographic hash to script tags. If the script content changes (from tampering or compromise), the hash won't match and the browser blocks execution.

<script
  src="https://js.stripe.com/v3/"
  integrity="sha384-abc123..."
  crossorigin="anonymous"
></script>

Generate hashes with: openssl dgst -sha384 -binary script.js | openssl base64 -A

SRI limitations

• Dynamic scripts. Scripts whose content changes on every load (CDN-versioned, personalized) cannot use SRI because the hash changes. You need CSP for authorization and monitoring for integrity.
• Third-party resistance. Some third-party vendors update scripts without notice, breaking SRI hashes. You need a process to detect breakage and update hashes.
• Tag managers bypass SRI. Scripts injected by GTM or similar tools cannot have SRI applied because the tag manager controls injection. Another reason to move tag managers off payment pages.

Building your script inventory

A script inventory is the foundation of 6.4.3 compliance. Here is the process:

1. Capture all scripts. Open your checkout page in Chrome DevTools. Go to Network tab, filter by JS. Record every script URL, domain and file size. Alternatively, use an automated scanner that loads the page in a real browser.
2. Classify each script. Is it first-party or third-party? Is it essential for the payment flow or can it be removed from this page?
3. Document justification. For each script, write why it needs to be on the payment page specifically. “It's always been there” is not a justification.
4. Remove unnecessary scripts. Move analytics, marketing pixels, chat widgets and A/B testing scripts to non-payment pages. This is the single most impactful step.
5. Assign ownership. Each script needs an owner who is responsible for reviewing changes.

Script inventory template

Tamper detection and monitoring

Requirement 11.6.1 mandates automated monitoring. Manual weekly checks are technically compliant but impractical and error-prone. Automated approaches:

• Browser-based monitoring. A headless browser (Playwright, Puppeteer) loads your payment page on a schedule, captures the full DOM and script list, compares against the approved inventory and alerts on differences. This is the “as received by the consumer browser” standard.
• CSP violation reporting. CSP with a report-uri endpoint captures every unauthorized script execution attempt in real time. This provides continuous monitoring, not just weekly.
• HTTP header monitoring. Check that security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options) have not changed. Missing or modified headers indicate potential compromise.
• Script hash comparison. Hash the content of each script weekly and compare against known-good hashes. Any change triggers an alert and re-authorization.

Platform-specific: Shopify, WooCommerce, Magento, BigCommerce

Shopify

Shopify handles PCI compliance for its hosted checkout, but merchants are responsible for:

• Scripts added via theme.liquid customizations that load on all pages including checkout
• Shopify apps that inject scripts into the storefront
• Custom code added via Checkout Extensibility
• Script tags added via the Admin API

Shopify's checkout runs on Shopify's domain with Shopify's CSP. Your ability to add CSP headers is limited. Focus on auditing which apps inject scripts and removing unnecessary ones from checkout. For a detailed breakdown of Shopify-specific obligations under these requirements, see our Shopify PCI DSS 4.0 compliance guide.

WooCommerce

WooCommerce leaves PCI compliance entirely to the merchant. WordPress's plugin ecosystem means the checkout page often loads dozens of scripts from various plugins. Specific concerns:

• WordPress plugins commonly enqueue scripts globally, including on checkout
• WooCommerce payment gateway plugins handle integration differently
• CSP implementation requires a plugin (like HTTP Headers) or server config (.htaccess/nginx)
• Use wp_dequeue_script() on the checkout page to remove non-essential scripts

Magento / Adobe Commerce

Magento has built-in CSP support since 2.4.x with a whitelist-based approach. However:

• Many extensions add their domains to the CSP whitelist during installation, widening the attack surface
• Magento's csp_whitelist.xml files from extensions should be audited
• Knockout.js templating on checkout can complicate CSP nonce implementation
• Payment modules (PayPal, Braintree, Stripe) each add their own script sources

BigCommerce

BigCommerce hosts its Optimized One-Page Checkout, handling base PCI compliance. Merchants are responsible for:

• Scripts injected via Script Manager that load on checkout
• Custom scripts added to the theme
• Third-party apps connected via the BigCommerce API

Compliance checklist

Vendor solutions compared

Several vendors specifically address PCI DSS 4.0 requirements 6.4.3 and 11.6.1:

c/side is the most accessible option for mid-market stores with a free tier. Enterprise solutions (Jscrambler, Akamai, Source Defense) suit larger operations. DIY Playwright monitoring is possible but requires ongoing engineering investment.

Penalties and enforcement

PCI DSS compliance is enforced by payment card brands (Visa, Mastercard, Amex) through your acquiring bank:

Timeline and key dates

For the full PCI DSS 4.0 timeline, see our dedicated guide. Key dates for 6.4.3 and 11.6.1:

Frequently asked questions

What are PCI DSS 4.0 requirements 6.4.3 and 11.6.1?

Requirement 6.4.3 mandates that every script on payment pages must be inventoried, authorized and integrity-verified. Requirement 11.6.1 requires a tamper detection mechanism that checks payment page content and HTTP headers at least every seven days.

When did these requirements become mandatory?

Both requirements became mandatory on March 31, 2025. They were future-dated best practices from PCI DSS 4.0's release in March 2022 until that deadline.

What is the penalty for non-compliance?

Monthly fines from $5,000 to $100,000, increased transaction fees, forensic investigation costs of $50,000-$500,000 if breached, fraud liability and potential loss of card processing ability.

Does this apply to Shopify stores?

Shopify handles PCI compliance for its hosted checkout, but merchants are responsible for scripts they add via theme customizations, apps and custom code on pages influencing the payment flow.

How do I comply with requirement 6.4.3?

Inventory every script on payment pages, document justification for each, implement Content Security Policy headers, add Subresource Integrity hashes and establish a script change review process.

What is Content Security Policy and how does it help?

CSP is an HTTP header telling browsers which script sources are allowed. It satisfies 6.4.3's authorization by blocking non-whitelisted scripts. Start with report-only mode to discover scripts before enforcement.

What is Subresource Integrity?

SRI is an HTML attribute containing a cryptographic hash of a script's expected content. If the script changes, the hash won't match and the browser blocks execution. This satisfies 6.4.3's integrity verification.

How often must I check payment pages under 11.6.1?

At least every seven days, or at a custom frequency defined in your targeted risk analysis. The check must evaluate the page as received by the consumer browser, meaning real browser rendering.

Does this apply to SAQ-A merchants?

Yes, with reduced scope. Visa's March 2025 FAQ clarified that SAQ-A merchants must ensure no scripts interfere with the payment redirect. The exact interpretation is evolving.

What tools can help with compliance?

c/side (free to $99/mo), Jscrambler, Akamai Page Integrity Manager, Source Defense and Complyko provide automated monitoring. You can also build custom Playwright-based monitoring for script hash comparison.