Payment-page scripts after PCI DSS 6.4.3 and 11.6.1: what assessors now expect
The two client-side requirements have been mandatory since 31 March 2025. Eighteen months on, buying a tool is the easy part. The hard part is proving authorization, integrity and tamper detection for scripts you do not fully control.
- Published
- September 16, 2026
- Reading time
- 11 minutes
- Written by
- MarkTillson Payment Security Practice
Most card data stolen from e-commerce in the last decade was not taken from a database. It was copied from the customer’s own browser, by JavaScript that the merchant had loaded onto its checkout page, often without realizing the script had changed. PCI DSS v4.0 answered this with two requirements, 6.4.3 and 11.6.1. They were best practice until 31 March 2025 and have been mandatory ever since, and they remain unchanged in substance in PCI DSS v4.0.1 (PCI SSC, June 2024).
Eighteen months into enforcement, the pattern we see is consistent. Organizations bought something, whether a Content Security Policy generator, a script-monitoring service or a tag manager with an approval workflow, and assumed the requirements were met. Assessors then asked for evidence the tool cannot produce on its own. This article explains what the two requirements actually ask for, where evidence usually falls short, and how SAQ A merchants should read the January 2025 change to their questionnaire.
The attack the requirements were written for
A payment page is assembled in the consumer’s browser from many sources: the merchant’s own code, analytics, consent banners, A/B-testing frameworks, chat widgets, fraud tools and the payment service provider’s scripts. Each of those sources can load further scripts. If any link in that chain is compromised (a vendor’s CDN, a stolen developer credential, an abandoned domain that a script still references), an attacker can add a few lines that read form fields or intercept the payment iframe’s messages and send the data elsewhere.
Server-side controls do not see this. The merchant’s web application firewall, file-integrity monitoring and vulnerability scans all look at what the server sends. The skimmer lives in what the browser executes, and it may appear only for some visitors, some regions or some times of day. That is why both requirements are framed around the page as received by the consumer’s browser.
What 6.4.3 asks for
Requirement 6.4.3 applies to all payment-page scripts that are loaded and executed in the consumer’s browser. For each one, the entity must have:
- A method to confirm the script is authorized. Someone with the authority to do so has decided this script belongs on the payment page.
- A method to assure the integrity of each script. The script executing is the one that was authorized, not a modified version.
- An inventory of all scripts, with a written business or technical justification for why each is necessary.
The requirement is deliberately technology-neutral. Subresource Integrity hashes, a strict Content Security Policy, script-blocking proxies and commercial client-side monitoring can all contribute. None of them, alone, is the answer, because each covers a different part of the problem.
| Technique | Helps with | Limits to plan for |
|---|---|---|
| Subresource Integrity (SRI) | Integrity of static, versioned scripts loaded by a <script> tag | Breaks when a vendor updates a script in place; does not cover dynamically injected scripts or inline code |
| Content Security Policy (CSP) | Authorization by source; can restrict where data is sent (connect-src, form-action) | Allows anything from an allowed origin; permissive policies with unsafe-inline add little |
| Client-side monitoring service | Inventory discovery, behavior change detection, alerting | Only as good as the review process behind the alerts; coverage depends on how it observes pages |
| Governed tag manager | Authorization workflow and change history for marketing tags | Often excluded from payment pages entirely, which is usually the better decision |
What 11.6.1 asks for
Requirement 11.6.1 is the detective companion. A change- and tamper-detection mechanism must alert personnel to unauthorised modification (including indicators of compromise, changes, additions and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser. The mechanism must evaluate the received headers and payment page at least weekly, or periodically at a frequency defined in the entity’s targeted risk analysis under requirement 12.3.1.
Two phrases matter. “As received by the consumer browser” rules out a check that only compares files on the web server. “Security-impacting HTTP headers” brings the Content Security Policy itself into scope: an attacker who can weaken the policy has already defeated part of your 6.4.3 control, and 11.6.1 expects you to notice.
If you choose a frequency other than weekly, the targeted risk analysis under 12.3.1 is part of the evidence. Assessors will read it to see whether the frequency reflects your actual exposure (release cadence, number of third-party scripts, traffic volume) rather than what the tool happens to do by default.
Where evidence usually falls short
In assessments and readiness reviews, the same gaps recur. None of them is a tooling gap.
The inventory describes the tool’s view, not the business decision
A monitoring service can list every script it observed. It cannot write the justification. An inventory where the “justification” column reads “detected” or “marketing” will not satisfy 6.4.3. Each entry needs an owner, a purpose, the data it can access and the reason it must run on the payment page rather than elsewhere.
Authorization is implied rather than recorded
“Our developers only add approved scripts” is a description of intent. Evidence looks like a change ticket, an approval in a governed tag manager, or a signed-off inventory version: something that shows who decided, and when, for each script currently on the page.
Alerts arrive, but nobody owns them
11.6.1 requires the mechanism to alert personnel. Assessors increasingly ask to see what happened to the last few alerts: who reviewed them, how quickly, and what they concluded. A queue of unacknowledged alerts is evidence that the control is not operating.
Scope stops at the merchant’s page
Where the payment form is an iframe from a PCI DSS-compliant payment service provider, the scripts inside that iframe are the provider’s responsibility. The scripts on the parent page that embeds it are not. A compromised parent page can overlay or replace the iframe, which is exactly why the parent page remains in scope for most e-commerce models.
What changed for SAQ A merchants
In January 2025 the PCI Security Standards Council revised SAQ A, the self-assessment questionnaire for merchants that fully outsource payment acceptance, typically through a redirect or an embedded iframe from a compliant provider. The revision removed requirements 6.4.3 and 11.6.1 from the questionnaire and added an eligibility criterion in their place: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce system.
This was widely read as relief. It is better read as a shift in where the work sits. The merchant still has to reach a defensible conclusion that its page is not susceptible to script-based attacks, and that conclusion needs a basis. In practice, the merchants who can sign that confirmation comfortably are the ones already doing much of what 6.4.3 and 11.6.1 describe: a small, known set of scripts on the page that hosts the payment iframe, protective headers, and some means of noticing change. The PCI SSC has published FAQ and guidance material on this point; check the current versions before you sign, and record how you reached the conclusion.
If an acquirer or assessor later asks why you were eligible for SAQ A, “the requirements were removed” will not be an answer. Keep the analysis that supports your eligibility confirmation with the rest of your compliance evidence.
A workable program in five steps
- Reduce first. The cheapest script to govern is the one that is not on the payment page. Remove analytics, heat-mapping and marketing tags from checkout wherever the business can live without them. Every removal shortens the inventory, simplifies the CSP and reduces alert noise.
- Inventory from the browser. Build the inventory from what real browsers execute, including scripts loaded by other scripts, rather than from the repository. Record owner, purpose, data access and justification for each.
- Choose integrity mechanisms per script type. Use SRI for static, versioned assets; a nonce- or hash-based CSP for first-party code; and contractual and technical controls (change notification, version pinning, or self-hosting) for third-party scripts that change in place.
- Make detection someone’s job. Configure 11.6.1 detection to cover script content and security-impacting headers, route alerts to a named team, and define what “reviewed” means. Test it by making an authorized change and confirming the alert arrives.
- Connect it to change management. Every release that touches checkout should update the inventory and the expected baseline. If your detection fires on every deployment, the baseline process is broken, not the tool.
What a good evidence pack contains
When we prepare clients for assessment, the evidence pack for these two requirements typically includes: the current script inventory with justifications and approvals; the CSP and other security headers as served, with change history; the integrity mechanism for each script category; configuration and coverage of the detection mechanism; a sample of recent alerts with their review records; and, where relevant, the 12.3.1 targeted risk analysis supporting the evaluation frequency. An assessor should be able to pick any script on the live page and follow it to an owner, a decision and a control.
Key takeaways
- Tools discover; people authorize. 6.4.3 needs recorded business decisions behind the automated list.
- “As received by the browser” means server-side integrity checks alone do not meet 11.6.1.
- Headers are in scope. A weakened Content Security Policy is an event your detection should catch.
- SAQ A eligibility is a conclusion you must be able to defend, not an exemption.
- The best control is a shorter list. Remove every script checkout does not need.
Sources
- PCI Security Standards Council, PCI DSS v4.0.1, June 2024, requirements 6.4.3, 11.6.1 and 12.3.1.
- PCI Security Standards Council, Self-Assessment Questionnaire A, revision published January 2025.
- W3C, Subresource Integrity and Content Security Policy Level 3 specifications.
These two requirements now decide more e-commerce assessments than almost any others. Our PCI DSS practice will review your payment pages and evidence with an assessor’s eye, then carry you through to a clean Report on Compliance with your QSA.
