CSP vs script monitoring
One decides where code may come from. The other decides what it may do. They are complementary, and only one of them produces 6.4.3 evidence.
TL;DR
CSP vs script monitoring
CSP
A browser-enforced allowlist of origins. Real against XSS and unlisted sources, and not required by PCI DSS.
SCRIPT MONITORING
A record of what executed and what it did, with integrity pinned to the payload. Produces the 6.4.3 inventory and the 11.6.1 change record.
THE OVERLAP
Small. They solve different problems, and only one of them produces 6.4.3 and 11.6.1 evidence.
Short on time? The compromised-vendor case is where CSP alone stops being enough.
What is the difference between a CSP and script monitoring?
A Content Security Policy controls which origins a browser may load scripts from, while script monitoring records which scripts actually executed, whether their contents changed, and what they did. The shorthand is that a CSP governs origin and script monitoring governs behaviour. Both are useful and they address different failures. A CSP stops a script loading from a source you never approved. Script monitoring notices that a source you did approve is now serving something different, or doing something new. Only the second produces the artefacts PCI DSS 6.4.3 asks for.
Requirement 6.4.3 is an authorisation record: every script on the payment page, where it came from, and why it is allowed to be there.
Side by side
Content Security Policy
Script monitoring
Enforced by
The browser
The tag, plus analysis off the page
Governs
Where code may load from
What code did once loaded
Blocks an unlisted origin
Yes
Yes
Blocks inline script
Yes, with nonces or hashes
Yes, by behaviour
Detects a compromised but allowed vendor
No
Yes, payload hash changes
Sees which script read the card field
No
Yes
Produces a per-script justification
No
Yes
Records HTTP header changes
No
Yes
Cost
Free, your own effort
A product
Satisfies PCI DSS 6.4.3
No
Yes, for the technical control
Where CSP stops: the compromised vendor
The case that matters. You allow cdn.vendor.com in script-src because you use their tag. The vendor is breached. The script at that same URL now contains skimmer code.
The browser loads it, because the origin is permitted. The skimmer reads the card field, because there is no privilege boundary between scripts on a page. It posts the data to a destination the attacker chose, and a competent attacker picks one already in your connect-src. No violation report is generated, because nothing violated the policy. Your CSP worked perfectly and the card was stolen.
The compromised-vendor case is the one a policy cannot see.
Where script monitoring stops
Being even-handed: script monitoring is not browser-enforced. It is a tag on the page, and a determined attacker can study a client-side script. It also says nothing about your servers, your network, or your data at rest. And it is a product you pay for, where a CSP is a header you write.
The mitigation for the first point is that a range of detections run off the page against a copy of the script fetched independently, so a script that avoids the in-page hooks still leaves a content hash and an archived payload to diff.
Do you need both?
No, and this is where we part company with most of the category. PCI DSS does not require a Content Security Policy, and a CSP produces none of the three things 6.4.3 asks for.
A policy also has a practical problem that rarely survives contact with a real checkout. Write it strictly and it blocks legitimate vendor scripts, so someone loosens it under pressure on a release day. Write it loosely and it permits the origin an attacker is already using. A large share of production policies end up carrying unsafe-inline, at which point most of the protection people believe they have is gone.
If you already run a CSP, keep it. It is a real control against unlisted origins and injected inline script. Just do not count it towards 6.4.3 or 11.6.1, and do not treat it as the thing standing between a compromised vendor and your card fields, because it is not.
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
Yes, if PCI DSS 6.4.3 applies to you, for two reasons. A CSP produces no inventory, no per-script justification and no integrity assurance, which are the three things 6.4.3 asks for. And a strict CSP does not detect a compromised but allowed vendor.
No. PCI DSS does not require a Content Security Policy, and a CSP does not satisfy 6.4.3 or 11.6.1 on its own. CSP was designed for a different problem: constraining inline script and controlling which origins may load resources. In practice a policy lands in one of two failure modes. Too strict, and it blocks legitimate vendor scripts and breaks the page. Too permissive, and it allows the thing you were worried about, which is why so many production policies carry 'unsafe-inline' and provide far less protection than they appear to. Either way it produces none of the three artefacts 6.4.3 asks for: no inventory, no per-script justification, and no integrity assurance.
The order matters: inventory first, then the CSP. Writing a policy without knowing what currently executes produces either a broken site or a permissive policy, and the permissive policy is the more common outcome.
No. Violation reports tell you what was blocked by policy. 11.6.1 asks for detection of changes to payment page content and HTTP headers with alerting to personnel, which is a different record.
No, negligibly. It is a header the browser evaluates while parsing. The cost is in the engineering effort to get the policy right, not in runtime performance.
This is very common, and it means your policy provides much less XSS protection than it appears to. It still restricts external origins, which is worth something. It also makes monitoring more valuable, because injected inline script is exactly what you are no longer blocking.
Yes, this is a genuinely useful side effect. The inventory tells you which origins actually load on which pages, which is precisely the input a correct allowlist needs and the thing most teams lack.
No. Both are client-side controls concerned with code executing in the browser. Server-side attacks need server-side controls, and a WAF, patching and access control are not replaced by either of these.
No, not by name. PCI DSS 6.4.3 and 11.6.1 describe outcomes rather than mandating a specific technology. A CSP contributes to meeting them and does not satisfy either on its own.
Where it is practical. SRI pins the exact contents of a file and is excellent for static assets you control. It breaks when a third party legitimately updates their script, which is why it is rarely used on vendor tags.
Related articles
Technical
Content Security Policy: a complete guide
What a CSP does, how to deploy one without breaking your site, and the gap it leaves open.
Technical
Subresource Integrity: what SRI solves and what breaks
Why SRI is excellent for static assets and almost unusable for third-party tags.
Technical
JavaScript security: the client-side threat model
What actually goes wrong in the browser, and which controls address which failure.
Technical
JavaScript obfuscation and de-obfuscation
Why malicious scripts are obfuscated, the common techniques, and how they get unpacked.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.