The Shift
What PCI DSS 4.0 requires on your payment pages
For most of its history, PCI DSS protected card data on the server and in transit, but treated the browser as out of scope. PCI DSS 4.0 changed that. Two new requirements — 6.4.3 and 11.6.1 — put client-side security on the compliance agenda for the first time, and they were written with one threat in mind: Magecart.
Magecart is the umbrella term for the criminal groups that inject malicious JavaScript — a digital skimmer — into payment pages to read card details directly from the form as they are entered. Because the skimmer runs in the customer's browser, server-side controls never see it. The breaches at British Airways and Ticketmaster are the best-known examples. How Magecart attacks work →
The future-dated requirements of PCI DSS 4.0, including 6.4.3 and 11.6.1, became mandatory on 31 March 2025.
The Requirement
Requirement 6.4.3 explained
Requirement 6.4.3 applies to every script loaded and executed on a payment page, and it sets out three obligations.
Authorise
Confirm each script is allowed
A method must be in place to confirm that every script executing on the page is authorised to run. A Content Security Policy is the browser-native way to do this.
Assure integrity
Detect unauthorised change
Each script's integrity must be assured so that tampering is detected. Subresource Integrity pins a script to a known-good version and blocks it if the file changes.
Inventory
Justify every script
A written inventory of every script must be kept, each with a business or technical justification for why it is necessary. The fewer scripts you run, the smaller the attack surface.
These map onto two browser standards that predate PCI DSS 4.0 by years: Content Security Policy for authorisation, and Subresource Integrity for integrity. The inventory is where policy meets housekeeping — you need a living record of what runs, why, and proof it is still exactly what you authorised. See how Script Watch inventories your scripts →
Ready to implement? Follow our step-by-step 6.4.3 implementation guide →
The Requirement
Requirement 11.6.1 explained
Requirement 6.4.3 gets your payment page into a known-good state. Requirement 11.6.1 keeps it there. It calls for a mechanism that detects unauthorised modification of the security-impacting HTTP headers and the script content of payment pages, and alerts on change — continuously, as the page is received by the consumer's browser.
This is a detective control, and it is where real-time reporting becomes essential. A CSP configured with a reporting endpoint turns every policy violation into an alert: the moment an unauthorised script attempts to load, or an authorised one is tampered with, a report is generated from the real browser session. See how Policy Watch detects CSP drift →
Ready to implement? Follow our step-by-step 11.6.1 implementation guide →
Not quarterly. Not on a schedule. Continuously — because that is how fast a skimmer appears.
Eligibility
SAQ A vs SAQ A-EP: who this applies to
The Self-Assessment Questionnaire is how eligible merchants attest to compliance. Even merchants who embed a payment provider's page in an iframe — and never directly touch card data — still control the parent page hosting it, which is why client-side security reached even the lightest-touch merchants.
Requirements 6.4.3 and 11.6.1 were removed from SAQ A in early 2025, but a new eligibility condition took their place: merchants must confirm their site is not susceptible to script-based attacks. PCI SSC FAQ 1588 then clarified that using the techniques described in 6.4.3 and 11.6.1 is the practical way to meet that condition. In effect, the removed requirements returned as the recommended control.
| Report URI covers |
Doesn't replace |
| Script inventory and change detection |
Penetration testing |
| CSP enforcement and violation logging |
Secure code review |
| Behavioural data exfiltration monitoring |
WAF or edge security |
| Audit-ready evidence generation |
Vulnerability remediation |
Compliance
The evidence auditors actually expect
The gap most organisations face isn't awareness of the requirements — it's the difference between having a control and being able to prove it worked. A script inventory in a spreadsheet satisfies the letter of 6.4.3 the moment you create it, but says nothing about what ran a week later. A CSP deployed without violation monitoring might be enforcing your policy, or silently failing.
PCI DSS 6.4.3 doesn't accept ‘we think we're compliant.’ A policy you can't prove is working isn't a control — it's a hope.
Report URI captures what actually happens in your users' browsers and turns it into structured, exportable evidence mapped directly to 6.4.3 and 11.6.1: a timestamped script inventory with authorisation status, change logs showing what was modified and when, and a record of CSP enforcement over time. Because everything works through the browser's native Reporting API, there is no agent to install and no traffic routed through a third party. See exactly how Report URI meets 6.4.3 and 11.6.1 →
Take it to your assessor: get the PCI DSS 6.4.3 & 11.6.1 evidence pack — a QSA-ready mapping of each requirement to the evidence you can export, available on this site and as a branded PDF download.
Get Ready
A practical 6.4.3 & 11.6.1 readiness checklist
The technical approach is the same regardless of which SAQ you complete. Work through these steps — grouped by the requirement each one satisfies — to get a payment page into a defensible state.
Requirement 6.4.3 — authorise, assure integrity, inventory
Inventory every script on the payment page and remove anything without a written justification
Authorise the scripts that remain with a Content Security Policy scoped to the payment page
Pin third-party scripts to known-good versions with Subresource Integrity
Requirement 11.6.1 — detect and evidence change
Add a CSP reporting endpoint so every violation is captured from real browser sessions
Alert on any change to the deployed policy, security-impacting headers, or payment page scripts
Export the inventory, change logs and enforcement history as audit-ready evidence
FAQ
Frequently asked questions
Requirement 6.4.3 requires that every script on a payment page is authorised, has its integrity assured, and is inventoried with a written business or technical justification for why it is needed. It exists to prevent Magecart-style skimming attacks that steal card data in the browser.
Requirement 11.6.1 requires a mechanism that detects unauthorised changes to the security-impacting HTTP headers and the script contents of payment pages, and alerts on those changes continuously rather than on a periodic schedule.
Requirements 6.4.3 and 11.6.1 were removed from SAQ A in early 2025, but a new eligibility condition requires SAQ A merchants to confirm their site is not susceptible to script-based attacks. PCI SSC FAQ 1588 confirms that using the techniques described in 6.4.3 and 11.6.1 is the practical way to meet that condition.
A Content Security Policy lets the browser enforce which scripts are authorised to run and restricts where data can be sent. With a reporting endpoint it also produces a continuous record of what was blocked and allowed, which supports both the authorisation obligation of 6.4.3 and the change detection obligation of 11.6.1.
The future-dated requirements of PCI DSS 4.0, including 6.4.3 and 11.6.1, became mandatory on 31 March 2025.
Auditors expect a timestamped script inventory with authorisation status, change logs showing what was modified and when, and a record of CSP enforcement covering what was blocked and allowed over time. Report URI produces this as structured, exportable, audit-ready evidence.
Prove PCI DSS compliance on your payment pages.
One header. No infrastructure changes. Continuous, audit-ready evidence from day one.
