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.

Why Is This Now Mandatory?

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.

How to Implement Control 6.4.3

1. Script Authorization

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

2. Script Integrity Verification

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.

3. Script Inventory & Business Justification

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.

Tools to Monitor CSP and Script Integrity

securityheaders.com

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:

• CSP header is present and active
• script-src is tight (only authorized domains/files)
• SRI hashes are included when appropriate

Snyk API & Web Scanning Tool (free tier)

Snyk offers a free API and web scanning service that can:

• Periodically crawl your payment pages
• Detect unauthorized or new scripts
• Alert if integrity has changed or an unknown domain is loading JS

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.)

Sample Implementation Workflow

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.

Why This Works

• CSP enforces script authorization by specifying allowed domains/files.
• SRI and runtime hashing support script integrity assurance.
• Inventory + justification addresses PCI's documentation requirement.
• Snyk or similar scanners fulfill continuous monitoring, supporting both 6.4.3 and adjacent control 11.6.1 for change detection.

Wrapping It Up

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.