Payment Page Security: Embracing PCI 6.4.3 and 11.6.1
As we approach the transition for several new PCI 4.0 requirements going from Best Practices to Full Requirements, we wanted to take a moment to highlight two of the most significant changes and provide guidance on how to maintain compliance while also strengthening the security posture of your payments pages.
There are two key requirements coming into force at the end of March 2025: PCI 6.4.3 and 11.6.1. Both new requirements were introduced in PCI DSS version 4.0 to address the growing threat of online card-skimming attacks like Magecart.
Magecart and similar cybercrime groups insert malicious scripts into checkout pages, silently exfiltrating payment data to their own servers. They do this in two primary ways:
- Supply-Chain Attacks: Scripts from third-party service providers, such as web analytics, chat widgets, etc. may be compromised, and malicious code can be injected. When the payments page includes these scripts, the malicious code is injected, and the card-skimming code is executed.
- Script Injection Attacks: Vulnerabilities in content management systems, outdated plugins, or unsecured dependencies can be exploited to inject unauthorized scripts. These scripts then execute on the payments page and they can steal payment information.
To address these threats, PCI DSS 4.0 added two new requirements:
- PCI DSS 6.4.3 requires organizations to create an inventory of script resources used in their payments pages such that each resource is: authorized, has integrity checking, and has a documented justification for its use.
- PCI DSS 11.6.1 requires organizations to implement monitoring and alerting for their payments pages to detect unauthorized changes.
These two requirements are important, and direct us to two open web standards: Subresource Integrity and Content Security Policy.
In March 2025, the PCI Council published a guide on implementing these requirements, which can be found in their document library: Payment Page Security and Preventing E-Skimming - Guidance for PCI DSS Requirements 6.4.3 and 11.6.1
If you are an SAQ A merchant, these two requirements don’t apply to you, but you will be required to attest that your site “is not susceptible to attacks from scripts that could affect [your] e-commerce system(s).”
PCI DSS 6.4.3: Script Inventory, Authorization, and Integrity
Customers using Basis Theory to build their payments pages can meet this requirement by utilizing the cryptographic hashes we publish for every new version of our JavaScript libraries.
If you use our Web Elements for your payments page, you can simply add the integrity attribute to the script tag that imports the library. The browser then verifies the contents of each script file it loads against the expected hash. If an attacker tries to inject malicious code into the Basis Theory library, the hashes will no longer match, and the browser will prevent the malicious code from executing.
We have also created a new endpoint where script hashes can be verified for every new version of the library, for example https://js.basistheory.com/sri/?version=1.9.0.
To meet the full requirement, make sure you have listed Basis Theory, and any other third-party scripts that your payments page uses in your script inventory, along with a justification. PCI DSS doesn't specify what the inventory needs to look like, and something as simple as a spreadsheet will suffice for many organizations.
PCI DSS 11.6.1: Script Monitoring and Alerting
Continuing our theme of open web standards, the modern browser offers an additional feature that the PCI DSS points us to for this requirement: Content Security Policy. For this requirement, there is even less for you to do if you’re using Basis Theory Elements.
We have implemented monitoring on these same script resources using CSP’s report-uri capability, which is enabled by default for all Basis Theory customers. Here again, if an attacker attempts to inject an unauthorized script into your payments page, CSP will prevent that code from executing, and will notify Basis Theory that the attempt was blocked.
Securing Other Third-Party Scripts
Note that if you are using other third-party JavaScript libraries in your payments page, you will need to create equivalent controls for the inventory, authorization, integrity checks, and monitoring for each of those resources as well.
The simplest way to meet the requirements is by removing any scripts from your payments pages that aren’t strictly necessary for the page to function. This is a simple matter of minimizing the resources that your payments page depends on. It reflects the security principle of Attack Surface Reduction—one that we highly value at Basis Theory.
Other tokenization services have decided to punt on these requirements and instead are recommending their customers integrate additional third-party services to monitor their payments script security.
Stripe has stated that it has no plans to support sub-resource integrity for its JavaScript libraries. Instead, it has committed to using “proprietary script management systems” to monitor script integrity. This approach will allow Stripe to maintain PCI compliance, but it leaves much to be desired for its customers in terms of the security and transparency that SRI provides for the broader Web.
Basis Theory has taken a different approach. We want to empower our customers by lifting the heavy PCI compliance for them and providing the tools to manage payment pages—in the way that fits your business.
