PCI DSS 6.4.3: All payment page scripts that are loaded and executed in the consumer’s browser
PCI DSS v4.0.1 control 6.4.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 6.4.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.4
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.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
Summary
Know every script that runs on your payment page, be able to show each one is authorised and unmodified, and keep a written reason for why each is there.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 6.4.3.a | Examine policies and procedures to verify that processes are defined for managing all payment page scripts that are loaded and executed in the consumer’s browser, in accordance with all elements specified in this requirement. |
| 6.4.3.b | Interview responsible personnel and examine inventory records and system configurations to verify that all payment page scripts that are loaded and executed in the consumer’s browser are managed in accordance with all elements specified in this requirement. |
Mandatory since 31 March 2025, and written in response to digital skimming. 6.4.3.a tests that you have a defined process; 6.4.3.b interviews your people and examines the actual inventory and configuration. The three bullets are separate obligations: authorisation, integrity, and a justified inventory. Meeting two of three fails the control. Note that this is the authorisation half of the problem and 11.6.1 is the detection half, so they are assessed together in practice.
What to prepare
- A script inventory for every payment page, listing each script, its origin, and a written business or technical justification.
- Evidence of the authorisation method: who approves a new script, and the record of those approvals.
- Evidence of the integrity method, such as Subresource Integrity hashes, a Content Security Policy with strict-dynamic and nonces, or an equivalent.
- The change process that keeps the inventory current when a script is added or updated.
How to implement it
1. Enumerate what actually loads in the browser, not what you think loads. Scripts injected by a tag manager, an analytics vendor, a chat widget or an A/B testing tool all execute on your payment page and all count. View the page as a consumer browser sees it, because a server-side listing of your own assets will miss every third-party script.
2. Decide the authorisation route and make it a gate. In practice this means a named approver and a record, tied into your change process from 6.5.1. An inventory that is updated after the fact documents what happened; it does not authorise anything.
3. Choose an integrity mechanism you can actually operate. Subresource Integrity is the clearest answer for static third-party scripts, but it breaks when the vendor updates the file, so it needs a process for rotating hashes. A strict Content Security Policy is often more practical for scripts that change frequently. Whichever you pick, the assessor will ask how it fails safe.
4. Reduce the surface first. Every script you remove from the payment page is one you no longer have to authorise, hash and justify. The cheapest way to pass this control is to have fewer scripts, and an iframe-isolated payment form can take the page out of scope for much of it entirely.
Where this commonly fails
- Treating a web application firewall as sufficient. This control is about authorising and assuring scripts, not filtering traffic.
- A tag manager that lets marketing inject arbitrary scripts into the payment page, which defeats the inventory the moment it is written.
- Subresource Integrity hashes that were correct at implementation and now block a legitimately updated vendor script, so someone quietly removed the integrity attribute.
- An inventory that lists scripts but has no justification column, when the written justification is an explicit part of the requirement.
How PCIComplianceHub helps
Our Payment page script inventory inventories every script that loads on a monitored payment page, hashes each script body so a later change is detectable, and records the decision and justification for each.
Scope note. It inventories the scripts it finds on the pages you monitor. Deciding that a page is your payment page, and that the justification for each script is adequate, remains yours.
Signed in, you can retrieve your organisation's evidence for 6.4.3 as JSON: what the scanner has recorded, with the scope note above attached to it.
Related controls
Others in section 6.4:
| Control | What it requires |
|---|---|
| 6.4.1 | For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing… |
| 6.4.2 | For public-facing web applications, an automated technical solution is deployed… |
← 6.4.2 · All controls · 6.5.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.