CSP vs Script Monitoring: Do You Need Both?

Transcript

For PCI DSS 6.4.3, you need script monitoring, and if you run a CSP, keep it. A CSP controls where scripts may load from. Monitoring records what ran, whether it changed, and what it did. One thing people mix up: CSP violation reports aren't 11.6.1 evidence. They tell you what the policy blocked. 11.6.1 asks you to detect changes to the payment page and its headers, and alert a person. Side by side. The browser enforces a CSP, and it governs where code may load from. Monitoring records what code did once it loaded: which script read the card field, whether an allowed vendor changed its code, and every header change. Here's the case that matters. You allow a vendor's CDN in your policy because you use their tag. The vendor is breached, and the script at that same address now contains skimmer code. The browser loads it, because the origin is allowed. The skimmer reads the card field and posts it to a destination already in your policy. No violation report is sent, because nothing broke the policy. Monitoring pins the payload, not the address. When the code at an allowed address changes, its hash changes, and that's an alert. So is a script reading the card field, or sending data somewhere new. To be fair to CSP. It's a real control against unlisted origins and injected inline script, and it's a free header you write. Monitoring isn't browser-enforced, it's a product you pay for, and it says nothing about your servers. But PCI DSS doesn't require a CSP, and it produces none of what 6.4.3 asks for. So the order matters: inventory first, then write the policy from what actually runs. In Script Monitoring, every header change, your CSP included, lands in the weekly evidence pack next to your script inventory. It's free for 1,000 page views a month, with CSP report collection included. Pro starts at $99 a month. Start for free at scriptmonitoring.com.