Control 6.4.3 falls under Requirement 6 (“Develop and maintain secure systems and software”) and specifically targets scripts loaded on payment pages in the consumer’s browser. It requires that:
“A method is implemented to confirm that each script is authorised.”
“A method is implemented to assure the integrity of each script.”
“An inventory of all scripts is maintained with written justification as to why each is necessary.”
These obligations address growing threats like Magecart-style attacks that inject malicious JavaScript into checkout flows.
Although PCI DSS 4.0 introduced these requirements, PCI 4.0.1, released June 11, 2024, elevated the guidance into a normative requirement and clarified that the justification must reflect “a business or technical justification as to why each is necessary”, now part of the requirement itself, not just guidance.
As of April 1, 2025, 6.4.3 is no longer optional—every script on a payment page must meet these criteria.
Use Content-Security-Policy (CSP) headers to restrict which domains or specific scripts can run. As the PCI guidance notes: CSP is “designed for the purpose of authorising scripts,” and can help satisfy authorization requirements.
Example:
Content-Security-Policy: script-src 'self' https://cdn.paymentwidget.com; default-src 'self';
You can even specify exact JS files instead of whole domains! For a great tutorial on CSP check out Scott Helme's Content Security Policy - An Introduction
Implement Subresource Integrity (SRI) hashes when loading third‑party JS to ensure no tampering, alongside monitoring integrity continuously. CSP + SRI helps prove that scripts haven’t changed since approval.
Some merchants go further with runtime integrity monitoring solutions to detect code alterations, especially for dynamic third‑party scripts.
Maintain a living inventory of scripts on your payment pages. For each script, document why it exists (e.g. analytics, checkout widget, fraud prevention), and regularly review/update it. This justification requirement moved from “guidance” to a normative part of the requirement in 4.0.1.
Use securityheaders.com to validate your CSP header configuration. Their scanner flags missing headers, overly permissive settings (e.g. script-src *), and CSP implementation issues.
This tool helps confirm:
script-src is tight (only authorized domains/files)Snyk offers a free API and web scanning service that can:
These features align with PCI 11.6.1 (change detection requirement), providing continuous monitoring beyond static CSP. (It’s compliant with 6.4.3’s “integrity” and inventory tracking objectives too.)
| Step | Action |
|---|---|
| 1. Inventory | Map all JS assets on your payment page (own, third-party). Document business justification. |
| 2. CSP & SRI | Deploy CSP header and SRI hashes to lock down script sources and verify file integrity. |
| 3. Baseline | Capture baseline page snapshot (scripts + headers). |
| 4. Monitoring | Use Snyk Web/API scan to crawl weekly. Alert on script changes or new sources. |
| 5. Review | Update inventory, justification, CSP / hash values as scripts evolve. Repeat quarterly or on change. |
Control 6.4.3 isn’t just bureaucratic checkboxing—it’s a response to real-world client-side threats that traditional WAFs can’t stop. By deploying tight CSP headers, using SRI, maintaining a script inventory with business justification, and scanning regularly with tools like securityheaders.com and Snyk’s free tier, you can satisfy 6.4.3 and demonstrate your security approach in PCI reports.
Let Payments Therapist guide your audit prep, implementation, and monitoring strategy—we handle the compliance plumbing and let you focus on building payments experiences, not rewriting CSP policies.