PCI DSS Requirements 6.4.3 and 11.6.1: A Practical Guide to Payment Page Script Security
We have written repeatedly about Magecart-style digital skimming — how attackers slip malicious JavaScript into checkout pages and quietly siphon card numbers to servers they control. PCI DSS 4.0 finally answered that threat with two requirements aimed squarely at the browser: PCI DSS 6.4.3, which governs the scripts allowed to run on payment pages, and 11.6.1, which requires detection of tampering. Both moved from “best practice” to mandatory on March 31, 2025, and they remain among the most misunderstood controls in the standard. This guide covers what they actually demand and how to implement them without rebuilding your checkout.
Quick answer: Requirement 6.4.3 requires merchants to inventory every script on browser-loaded payment pages, authorize each one with a written business justification, and assure its integrity. Requirement 11.6.1 requires a mechanism that detects unauthorized changes to payment page scripts and security-relevant HTTP headers, alerting personnel at least weekly — ideally continuously.
Why do these requirements exist?
Traditional PCI controls guarded servers and networks. But in a client-side skimming attack, the merchant’s servers are often untouched — the malicious code executes in the customer’s browser, injected via a compromised first-party file, a tag manager, a chat widget, or any of the dozen third-party scripts a modern checkout loads. The customer’s card data is stolen before it ever reaches the legitimate payment processor. Our breakdown of how Magecart attacks work covers the attack mechanics; 6.4.3 and 11.6.1 are the compliance response.
What does Requirement 6.4.3 actually require?
For all scripts that are loaded and executed on payment pages in the consumer’s browser, three things:
- An inventory. A maintained list of every script — first-party and third-party — with each one’s purpose. “We didn’t know that tag was there” is precisely the condition this eliminates.
- Authorization. A method to confirm each script is authorized, with a written justification for why it is necessary. This forces the useful conversation: does the analytics beacon, the A/B testing tool, the session-replay widget genuinely need to run on the payment page, or can it live everywhere else on the site instead?
- Integrity assurance. A method to assure the integrity of each script — confidence that the script executing today is the script you authorized.
What counts as a “payment page”?
Any web page that captures account data, or that affects how account data is captured — including the parent page that embeds a payment iframe. This last point surprises many merchants: even with a fully hosted iframe solution, the page hosting the iframe is in scope for these requirements in the eyes of most assessors, because a script on the parent page can overlay or replace the iframe. (The applicable SAQ A footprint has its own nuances; if you are unsure which questionnaire you fall under, start with our merchant’s guide to choosing the right SAQ.)
What does Requirement 11.6.1 require?
A change- and tamper-detection mechanism deployed on payment pages that:
- Alerts personnel to unauthorized modification — including additions, changes, and deletions — of security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser; and
- Runs at least once every seven days, or at a frequency defined by a targeted risk analysis. In practice, weekly is the floor, and continuous monitoring is the defensible norm — a skimmer that lives for six days before your weekly check is still a six-day breach.
Where 6.4.3 is preventive governance, 11.6.1 is detective: it assumes prevention will eventually fail and demands you notice quickly. That philosophy should sound familiar from our article on why detection time decides breach severity.
How can you implement 6.4.3 and 11.6.1?
There is no single mandated technology. The realistic toolkit:
| Mechanism | What it does | Strengths | Limitations |
|---|---|---|---|
| Content Security Policy (CSP) | Browser-enforced allowlist of script sources; violation reports can feed alerting | Native, free, powerful; report-only mode aids inventory-building | Allowlists domains, not content — a compromised allowed vendor still executes; policies are hard to maintain |
| Subresource Integrity (SRI) | Cryptographic hash on a script tag; browser refuses mismatched files | True content integrity for static scripts | Breaks on legitimately dynamic third-party scripts, which is most of them |
| Client-side monitoring services | Instrumented synthetic browsers or in-page agents observe actual script behavior and headers | Directly maps to both requirements; behavioral detection | Commercial cost; agent scripts themselves must be inventoried and protected |
| Iframe/redirect architecture | Moves card capture into a provider-hosted context | Radically reduces the attack surface the requirements must cover | Parent page still needs governance; overlay attacks remain possible |
| Server-side templating discipline + file integrity monitoring | Detects changes to first-party page sources | Catches server-side injection | Blind to third-party scripts modified at their origin |
Most compliant implementations layer two or three of these: for example, a minimized script set on a redirect or iframe page, CSP in enforcing mode, and a monitoring service or scheduled synthetic scan producing the weekly (or continuous) evidence for 11.6.1.
A pragmatic implementation sequence
- Discover. Run CSP in report-only mode or a crawler against the payment flow for two weeks. The resulting list of scripts is usually two to three times longer than anyone expected.
- Prune. Challenge every script’s presence on payment pages specifically. Fewer scripts means smaller inventory, smaller attack surface, easier audits. Marketing tags rarely survive honest scrutiny here.
- Document. Record each surviving script: name, source, purpose, owner, justification, integrity method. A spreadsheet is acceptable evidence; a stale spreadsheet is not.
- Enforce and monitor. Turn on your integrity and tamper-detection layers; wire alerts to a mailbox someone actually reads; define the response runbook for an alert.
- Operationalize. Add a payment-page review gate to your release process so new tags cannot appear without joining the inventory. Fold the evidence into the year-round habit described in building an audit-ready PCI DSS program.
Common failure patterns assessors see
- An inventory created once for the assessment and never updated — while the tag manager keeps deploying new scripts weekly.
- Treating a CSP header alone as full compliance while having no answer for header tampering or alerting under 11.6.1.
- Excluding the iframe parent page from scope without documented analysis supporting that position.
- Alerts routed to an unmonitored dashboard — a detective control nobody watches is a control that does not exist.
- Forgetting non-checkout capture points: donation forms, “update card” account pages, and pay-by-link landing pages are payment pages too.
Frequently asked questions
Do 6.4.3 and 11.6.1 apply if I use a hosted iframe or redirect?
The requirements still matter for the page that embeds or initiates the payment flow. Hosted solutions shrink the work dramatically but do not erase it — and your provider’s documentation should state which responsibilities remain yours.
Is a weekly scan really enough?
It is the minimum the standard names. Whether it is appropriate is a risk decision: skimming campaigns measured in hours argue strongly for continuous or daily monitoring on any meaningful transaction volume.
Can I just use SRI hashes on everything?
Only for scripts whose content is static. Most third-party vendors update their scripts without notice, which breaks SRI. Use SRI where it fits and layer other controls where it does not.
Who should own this control?
Jointly: engineering owns the technical mechanisms, but marketing and product own most of the scripts. Programs fail when security tries to govern tags it has no organizational authority to remove.
What evidence will my assessor want?
The current inventory with justifications, proof of the integrity mechanism, alert logs and their timestamps demonstrating the operating frequency, and at least one worked example of an alert being investigated.
These two requirements exist because the browser became the battleground. For the attacker’s view of that battleground, read our guides to Magecart skimming; for where these controls sit within your questionnaire obligations, see our upcoming comparison of SAQ A and SAQ A-EP integration choices.