These questions come from compliance teams I've talked to over the past six months. The new PCI DSS v4.0.1 requirements around payment-page scripts caught many organizations off guard. Requirement 6.4.3 demands that you inventory, authorize, and prove the integrity of every script that loads on your payment pages — and teams are scrambling to figure out what that actually means in practice.
Here's what people are asking in their security Slack channels, and what I've learned helping teams manage this.
Do I Need to Track Every Script on My Checkout Page?
Yes. Requirement 6.4.3 is explicit: you must maintain an inventory of all scripts executing on payment pages. This includes your own first-party code, analytics tags, chat widgets, fraud detection tools, and any third-party libraries they pull in.
This requirement exists because web skimming attacks — where attackers inject malicious code into payment pages to steal card data — have become a serious threat. Attackers compromise a single third-party script provider, and suddenly hundreds of merchants are leaking customer payment data.
Your inventory needs to include:
- Script source (URL or inline)
- Business justification for its presence
- Authorization details
- Expected behavior
Even if you're using an embedded payment iframe from your payment processor, the page hosting the iframe still loads scripts that can interact with the iframe or capture data before it reaches the iframe.
How Is This Different from Previous Practices?
Previously, many teams relied on Content Security Policy (CSP) headers and periodic manual reviews. You'd generate a hash of each authorized script and use CSP to block anything that didn't match.
That approach has a flaw: 30% of payment-page scripts change within any two-week window. Marketing swaps out an analytics tag. Your fraud vendor pushes an update. Your chat widget auto-updates. Each change breaks your hash, and suddenly you're either blocking legitimate functionality or constantly updating hashes.
The new requirement pushes you beyond simple file integrity checks. You need to understand what scripts are doing, not just verify they haven't changed. A script can have the same hash but start exfiltrating data to a new domain after the vendor gets compromised.
Hash-Based vs. Behavior-Based Monitoring
Hash-based monitoring creates a cryptographic fingerprint of a script file. If the file changes, the hash changes. Simple, but limited.
Behavior-based monitoring watches what scripts actually do at runtime:
- What domains do they connect to?
- What data do they access (form fields, localStorage, cookies)?
- Do they inject new scripts or iframes?
- Do they modify the DOM in unexpected ways?
For example, your analytics script has the same hash it's always had. But after a supply chain attack, it now sends payment form data to evil-domain.com in addition to its normal analytics endpoint. Hash-based monitoring sees nothing wrong. Behavior-based monitoring flags the new network connection immediately.
The challenge is that behavior-based monitoring requires continuous runtime analysis. You can't just run it once during deployment — you need to monitor production traffic.
Can We Block All Third-Party Scripts?
You probably can't, and here's why: Most payment pages rely on multiple third-party services that your business considers essential. Fraud detection tools reduce chargebacks. Analytics inform conversion optimization. Chat widgets support customers who have questions during checkout.
The better question is: Which scripts actually need to run on the payment page itself?
Move everything you can to post-purchase pages. Your marketing pixel doesn't need to fire until after the transaction completes. Your customer satisfaction survey can wait. Your A/B testing tool probably shouldn't be running on checkout at all.
For scripts that must stay, implement strict controls:
- Load them from specific, versioned URLs (not
latestor auto-updating endpoints) - Use Subresource Integrity (SRI) attributes where possible
- Document exactly what data they're authorized to access
- Set up alerts for any behavior changes
Implementing Without Overwhelming Your Team
Manual monitoring doesn't scale. If you have 30 scripts and 30% change biweekly, you're reviewing roughly 18 script changes per two-week sprint. That's not sustainable.
You need automation, but automation alone isn't enough. Here's a practical approach:
Initial Inventory (One-Time, Labor-Intensive):
- Audit every script currently on your payment pages
- Document business justification for each one
- Get explicit authorization from whoever owns that business function
- Remove anything that can't be justified
Ongoing Monitoring (Automated):
- Deploy runtime monitoring that tracks script behavior
- Set baseline expectations for each authorized script
- Alert on deviations: new domains, new data access, new injected resources
- Review alerts weekly, not daily (unless you see actual suspicious behavior)
Change Management (Semi-Automated):
- When marketing wants to add a new tag, they submit a request
- Security reviews the script's behavior in a test environment
- Approve or reject based on actual risk
- Add approved scripts to your monitoring baseline
The key is separating signal from noise. Don't alert on every minor script update — alert on behavior changes that matter for payment security.
Evaluating Monitoring Tools
First, verify that the tool supports PCI DSS v4.0.1 compliance. Ask vendors for documentation from a PCI Qualified Security Assessor (QSA) confirming their platform addresses Requirement 6.4.3.
Then evaluate technical capabilities:
- Does it monitor runtime behavior or just file hashes?
- Can it detect when a script starts communicating with new domains?
- Does it track what form fields scripts access?
- Can you set custom policies for different script categories?
- How does it handle dynamic scripts loaded by other scripts?
Also consider operational fit:
- How much manual configuration does initial setup require?
- What's the false positive rate in production?
- Can your team actually respond to the alerts it generates?
- Does it integrate with your existing security workflow?
Don't get sold on a tool that generates 500 alerts per day that you'll learn to ignore. You need something that surfaces actual risk without overwhelming your team.
Next Steps
Start with your current payment page scripts. Run a browser developer tools session and capture every network request during a test checkout. You'll probably be surprised by how many third-party connections happen.
For each script, ask: Does this need to be here? Can we move it? If it stays, what's the business justification?
Document your findings. Build your inventory. Then figure out how you'll monitor it going forward.
PCI DSS v4.0.1 has a transition period for new requirements, but Requirement 6.4.3 is already in effect. Your QSA will ask about it in your next assessment. Better to have an answer ready than to scramble when they show up.
The PCI Security Standards Council publishes supplemental guidance on script management. Review it. Your payment processor may also have specific recommendations for their integration method.
And if your team is already overwhelmed with other security work, remember: This requirement exists because web skimming attacks are real and costly. The work you put in now prevents the much worse work of responding to a breach later.
