Skip to content
MDView as Markdown

PCI DSS 6.4.3

Requirement 6.4.3 applies to every script loaded and executed on a payment page. It sets out three obligations: each script must be authorised, its integrity must be assured, and it must be inventoried with a written justification for why it is needed. This guide walks through meeting each one with Report URI.

PCI DSS v4.0.1, 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.
  • 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.

Note

This is a practical implementation guide, not compliance advice. Your QSA is the authority on how Requirement 6.4.3 applies to your specific environment.

Step 1: Inventory every script

You cannot authorise what you cannot see. The first step is a complete, current inventory of every script executing on your payment page.

Script Watch builds and maintains this inventory automatically from real browser reports, and alerts you when a new dependency appears. If you do not yet have a Content Security Policy, you can start in Report-Only mode purely to gather the inventory, with no blocking:

Content-Security-Policy-Report-Only: default-src * 'unsafe-inline' 'unsafe-eval'; script-src 'self'; report-uri {URL}

Every script that loads is reported, Script Watch records it, and you have the beginnings of your inventory. Review it and remove anything that isn't needed on the payment page — the fewer scripts you run, the smaller your attack surface and the simpler your justification.

Step 2: Authorise the scripts that remain

Once you know what belongs on the page, a Content Security Policy is the authorisation mechanism 6.4.3 calls for. The CSP declares exactly which sources are allowed to load scripts; anything else is reported to you as a violation.

The CSP Wizard builds a working policy for you from your reports. You can deploy that policy in Report-Only mode, which authorises your known-good scripts and reports any unauthorised script that appears — without blocking anything on the page:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' js.stripe.com; report-uri {URL}

A report-only policy is enough to meet 6.4.3: you have a method that confirms each script is authorised and alerts you to anything that isn't. You do not have to switch the policy to enforcing to be compliant. Moving to an enforcing Content-Security-Policy header — which actively blocks unauthorised scripts rather than only reporting them — is stronger protection you can adopt at your own pace, but it is not required for compliance.

Restricting connect-src and form-action in the policy goes further still, limiting where the page can send data and cutting off a skimmer's exfiltration route. See the Content Security Policy guide for the full directive reference.

Step 3: Assure script integrity

Authorisation confirms where a script came from; integrity confirms it hasn't been tampered with. The standard's guidance lists the mechanisms that satisfy this element, and Subresource Integrity is the first one named.

PCI DSS v4.0.1, Requirement 6.4.3, Guidance

The integrity of scripts can be enforced by several different mechanisms including, but not limited to:

  • Sub-resource integrity (SRI), which allows the consumer browser to validate that a script has not been tampered with.
  • A CSP, which limits the locations the consumer browser can load a script from and transmit account data to.
  • Proprietary script or tag-management systems, which can prevent malicious script execution.

The advised method: Subresource Integrity (SRI)

SRI is the mechanism the guidance lists first, and it maps directly onto the requirement to "assure the integrity of each script". You add an integrity attribute — a cryptographic hash of the expected file — and a crossorigin attribute to each <script> tag:

<script src="https://js.example.com/widget.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>

Before running the script, the browser recomputes the hash and compares it. If the file has been modified — by a compromised vendor, a hijacked CDN, or tampering in transit — the hashes no longer match and the browser refuses to execute it. That is exactly the "assure the integrity of each script" element, delivered by a browser-native standard with no third-party code on your page.

Note that the second mechanism in the guidance, "A CSP, which limits the locations the consumer browser can load a script from and transmit account data to", is the Content Security Policy you already deployed in Step 2 — so that step contributes here too.

Going further: enforce and report on SRI coverage

SRI on its own relies on every script tag being hand-maintained, and it says nothing when a new script appears with no integrity attribute at all. Report URI lets you close that gap and exceed the baseline the requirement asks for:

  • CSP Integrity - use your CSP to require SRI for scripts and stylesheets, and report on anything loaded without it, so a script that ships without a hash is caught rather than silently trusted.
  • Integrity Policy - enforce that all scripts and stylesheets on the page carry SRI, with full violation reporting.

Where plain SRI protects the scripts you remembered to hash, these turn integrity into an enforced, monitored policy across the whole page — stronger protection than 6.4.3 strictly requires, and a report trail that proves it is working.

Step 4: Keep the inventory current and exportable

6.4.3 is not a point-in-time exercise — the inventory must reflect what is running today, and you need to be able to show it. Because Script Watch is fed by live browser reports, your inventory stays current on its own, and you can export it, along with authorisation status and timestamps, as evidence for your assessor. The PCI DSS 6.4.3 & 11.6.1 evidence pack sets out exactly which artefacts map to this requirement.

Detecting and alerting on change over time is the job of Requirement 11.6.1 — continue with the PCI DSS 11.6.1 guide.

Start with Report URI

Already using us? Manage your monitored sites on Script Watch and build a policy with the CSP Wizard.

New to Report URI? These capabilities are available on a Business plan or higher, or free during your trial month — create a free account to get started.