PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1: What Ecommerce Merchants Must Do Now

PCI DSS v4.0.1 became fully mandatory in March 2025, and while most merchants have now heard about it, two specific requirements remain widely unaddressed: 6.4.3 and 11.6.1. Both target the same threat: malicious scripts injected into payment pages to steal card data, and both have concrete, testable compliance criteria.

If your store has a checkout page, these requirements apply to you regardless of which SAQ type you file.

Why These Requirements Exist

The Magecart attacks that hit British Airways (380,000 cards), Ticketmaster (40,000 cards), and hundreds of thousands of SMB ecommerce stores share a common mechanism: a malicious JavaScript snippet quietly appended to the payment page that exfiltrates card data as customers type it.

What made these attacks so damaging was how long they went undetected, weeks to months in most cases. The payment processor never saw anything unusual. The web server logs were clean. The card data disappeared entirely at the browser layer, before it was ever submitted.

PCI DSS v4.0.1 Requirements 6.4.3 and 11.6.1 exist specifically to close that gap.

Requirement 6.4.3: Script Authorisation and Integrity

Requirement 6.4.3 has three sub-requirements:

6.4.3.a Inventory: Maintain a documented list of every script authorised to execute on the payment page, including its purpose and who approved it.

6.4.3.b Integrity: Implement a method to confirm that each script has not been tampered with. Acceptable methods include:

• Subresource Integrity (SRI): add an integrity attribute to <script> tags pointing to third-party files. The browser verifies the hash before executing.
• Content Security Policy (CSP): restrict which script sources are permitted, using nonce-based or strict-dynamic policies.
• Script monitoring service: a third-party service that alerts on unauthorised script changes.

6.4.3.c Written justification: Every script on the list must have documented business justification for why it needs to be on a payment page.

What this looks like in practice

A Shopify store that uses Google Analytics, Facebook Pixel, a live chat widget, and Shopify's own checkout scripts might have 8 to 12 scripts loading on the payment page. Under 6.4.3, you need a written inventory like:

Script: Google Analytics (analytics.js)
Source: https://www.google-analytics.com
Purpose: Conversion tracking
Approved by: [name], [date]
Integrity control: CSP allowlist (google-analytics.com)

For scripts you host yourself or load from a CDN you control, SRI hashes are the cleanest solution. For third-party scripts that update frequently (where pinning a hash breaks when the vendor releases an update), CSP allowlisting is more practical.

Requirement 11.6.1: Change and Tamper Detection

Requirement 11.6.1 requires deploying a mechanism that detects unauthorised modifications to HTTP headers and the content of the payment page. Specifically:

• The mechanism must be capable of alerting on changes to HTTP security headers (CSP, SRI, X-Frame-Options, etc.)
• It must detect changes to page content that could indicate script injection
• Alerts must be reviewed at least weekly (or more frequently depending on risk)

Acceptable approaches include:

• Script monitoring services (e.g. Featurespace, c/side, Jscrambler) that baseline your payment page and alert on changes
• Automated integrity checks that diff the payment page HTML/scripts on a schedule and alert on unexpected changes
• Browser-side telemetry from a CSP report-uri that surfaces policy violations

A "check it weekly by hand" approach technically satisfies the letter of 11.6.1 if you document it, but it will not reliably detect a fast-moving attack and will not impress a QSA.

How to Know if You're Compliant

You are compliant with 6.4.3 and 11.6.1 if you can answer yes to all of the following:

1. Do you have a written inventory of every script on your payment page?
2. Does every script have a documented business justification?
3. Is there a technical control (SRI, CSP, or monitoring service) that would detect if any script was modified?
4. Is there an automated mechanism that would alert you if the payment page content or HTTP headers changed unexpectedly?
5. Is that alert reviewed at least weekly?

If any answer is no, you have a compliance gap, and more importantly, an unmitigated risk.

The Fastest Path to Compliance for SMB Merchants

For a Shopify or WooCommerce store on a limited budget:

1. Audit your payment page scripts: use browser DevTools (Network tab, filter by JS) to enumerate every script that loads. This takes 20 minutes.
2. Document the inventory: a Google Sheet is fine for this. Name, source URL, purpose, approval.
3. Remove scripts you can't justify: if you can't answer "why does this need to load on the checkout page?", remove it. This also reduces your attack surface.
4. Enable CSP headers: your hosting provider or CDN (Cloudflare, Vercel, etc.) can add these. A basic allowlist policy dramatically limits what can execute.
5. Add SRI hashes to self-hosted scripts: generate hashes with srihash.org and add integrity attributes to your <script> tags.
6. Set up weekly automated diffing: a simple script that fetches your checkout page and diffs it against a baseline is enough to satisfy 11.6.1 on a budget.

CyberShield Studio's free Website Security Checker identifies missing CSP headers, missing SRI attributes, and other 6.4.3/11.6.1 risk signals on any merchant URL, no account required.

Summary

Requirements 6.4.3 and 11.6.1 are not compliance theatre. They exist because Magecart-style attacks are real, ongoing, and disproportionately impact smaller merchants who lack the monitoring infrastructure to detect them. The requirements are achievable, even for a small team, if you approach them systematically.

If you're unsure where your store stands, start with the inventory. Everything else follows from knowing what's actually running on your checkout page.