The Requirements
What PCI DSS 6.4.3 and 11.6.1 actually ask for on your payment pages
Requirement 6.4.3 — Script authorisation and inventory
Every script executing on your payment pages must be authorised, inventoried, and documented — and kept that way over time, not just on audit day.
Requirement 11.6.1 — Continuous change detection
Unauthorised changes to your payment page headers and scripts must be detected. Continuously, not on a quarterly review cycle.
Both requirements exist for one reason: skimming attacks capture card data in the browser, where your server-side controls can't see them. The standard moved to the browser because the attackers already had.
The Evidence Gap
Why “we have CSP” doesn't satisfy your QSA
A Content Security Policy defines what should be allowed to run. It doesn't produce a record of what actually ran, and it won't tell you when the policy itself gets changed.
Your QSA is asking for evidence, not intent. “We have a policy” and “here's proof the policy held” are different conversations — and only one of them closes a finding.
This is the gap most teams don't see until the QSA names it, usually at the worst possible moment.
The Proof Layer
What auditable evidence actually looks like
Most client-side tools tell you when something looks wrong. For an audit, you need structured, exportable records your team and your auditor can work with:
| Evidence |
What it answers for the QSA |
| Script inventory with authorisation status and timestamps |
Is every script on the payment page authorised? |
| Change logs showing what was modified, when, and what it changed from |
Would you have detected an unauthorised change? |
| CSP enforcement history: what was blocked, what was allowed, over what window |
Is the policy actually holding in production? |
| Behavioural data on where page data actually travelled |
Did anything exfiltrate that shouldn't have? |
As Report URI's founder Scott Helme frames it from the Instructure Canvas breach: CSP isn't only a runtime block — it's a real-time integrity sensor for your execution environment. When something executes that shouldn't, the browser reports it, and that report is your evidence trail.
PCI DSS 6.4.3 doesn't accept “we think we're compliant.”
Continuous, Not Quarterly
Change detection is a compliance function, not a nice-to-have
A static spreadsheet reviewed each quarter isn't continuous monitoring, and 11.6.1 asks for continuous.
Manual script inventories break down the moment you're maintaining them across more than a handful of pages or domains.
Change detection with an audit trail turns “we check periodically” into “we can show you every change since the last audit.” See how Script Watch monitors your JavaScript →
Deployment
No agent, no proxy, no deployment risk
One reporting endpoint added to your existing Content Security Policy header. That's the deployment.
Report URI is browser-native, so there's no new dependency and nothing new in the request path to fail an availability review. Your site runs normally even if Report URI is unavailable.
This is reassurance for the person who signs off on the deployment — not the pitch. It's a header change, not a project.
Scope
What it covers, what it doesn't replace
| 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 |
Naming the limits is what makes the compliance claims credible. Report URI produces the evidence layer for what executes in the browser. It doesn't pretend to be the rest of your program. How to meet PCI DSS 6.4.3 and 11.6.1 on your payment pages →
In Practice
Trusted by teams meeting PCI DSS 4.0
Payment providers Paddle and REPAY use Report URI toward their PCI DSS 4.0 obligations — turning what executes on their payment pages into records they can put in front of an auditor.
The reason the requirements exist is on the same page: British Airways, Ticketmaster, and the European Space Agency were all hit by Magecart, the browser-based card skimming that 6.4.3 and 11.6.1 were written to catch. British Airways was fined £20,000,000 because an attacker edited a single file loading on their site. The code wasn't theirs. The penalty was.
Report URI was founded by Scott Helme, who finds and publicly discloses this class of attack from real CSP report data. Read the case studies →
Start generating audit-ready evidence.
One header. No infrastructure changes.
