PCI DSS 6.4.3 explained: managing payment page scripts

What the requirement says, in plain words

This is a paraphrase; the exact wording is in PCI DSS v4.0.1, available from the PCI SSC document library. Requirement 6.4.3 covers all payment page scripts that are loaded and executed in the consumer's browser, and has three parts:

1. Authorization. A method is in place to confirm that each script is authorized, meaning someone with the right to decide has agreed that this script may run on this page.
2. Integrity. A method is in place to assure the integrity of each script, meaning that the script that runs is the one that was approved and has not been altered.
3. Inventory and justification. A list of all scripts is kept, with a written business or technical reason why each one is necessary.

It sits in the part of PCI DSS about developing and maintaining secure systems and software, and it is a companion to requirement 11.6.1, which detects unauthorized changes. For why both exist, see why the PCI SSC created them.

Which scripts and which pages

The requirement is not limited to third-party scripts. Scripts you wrote, libraries you host, scripts loaded by a tag manager, and scripts loaded by other scripts are all scripts that execute in the browser on the payment page. PCI DSS v4.0.1 also added a note that the requirement applies to the scripts on a merchant's web page that includes a payment provider's embedded payment form, for example in an iframe. Whether and how it applies to your environment depends on how you accept payments; see 6.4.3 and 11.6.1 for SAQ A, SAQ A-EP and SAQ D, and confirm with your acquirer or assessor.

Ways to meet each part

PCI DSS leaves the method to you, and a QSA decides whether what you do meets the intent. Approaches commonly used include:

Authorization

• A documented approval workflow: who may approve a script, what information they need, and how the decision is recorded and dated.
• A technical control that enforces the approved list, for example a Content Security Policy that allows only approved script sources.

Integrity

• Subresource Integrity for static external scripts, so the browser checks the file against an approved hash.
• Hosting approved copies yourself and comparing their hashes with the approved values on a schedule.
• CSP hashes or nonces for inline scripts.
• Monitoring that compares the content the browser receives against an approved baseline, which also supports 11.6.1.

No one technique covers every case. A hash on a static file cannot help with a script a vendor changes every week, and a CSP allow-list does not tell you whether an allowed host's file has been altered. That is why many organizations combine methods.

Inventory and justification

The inventory must be real, which means built from what the browser loads, not from what the source code says. Each entry needs a reason that a reviewer can understand and test. See how to build a payment page script inventory.

What an assessor typically wants to see

Assessors differ, so ask yours, but evidence of this kind is usual:

• the current inventory for each payment page, with owner, purpose and justification for each script;
• records of who authorized each script and when, and how a change is approved;
• a description of the integrity method and evidence it is working, such as hashes, policy files and monitoring output;
• evidence that the inventory matches what the pages really load, and that it is reviewed and updated, not produced once;
• how new or changed scripts are handled between reviews.

Common mistakes

• An inventory taken once from the source code, missing scripts added by a tag manager or loaded by other scripts.
• Justifications such as "marketing" or "vendor request" that do not say why the script is needed on a payment page.
• Counting only the main checkout page and forgetting the other steps of the flow.
• Treating an iframe from a payment provider as removing all obligations for the page around it.