Does Subresource Integrity (SRI) Satisfy PCI DSS 6.4.3?
Subresource Integrity partly satisfies PCI DSS 6.4.3: it covers the integrity element for the scripts you can apply it to, but not the inventory or the written business justification per script. This video is fair to SRI: how the integrity attribute works, where it works well (your own static assets, pinned library versions, anything with a build step), why it breaks on third-party tags that vendors update without notice, why 6.4.3 says 'assure the integrity' rather than 'use SRI', how payload pinning gets the same assurance without the outage, and how SRI and a CSP answer different questions.
Full answer: Subresource Integrity: What SRI Solves and What Breaks
Transcript
Partly. Subresource Integrity covers the integrity part of 6.4.3, for the scripts you can apply it to. It doesn't produce the inventory or the written justification per script, the other two parts. Script Monitoring is one tag that watches every script on your payment pages, in every session, and records what each one contains. SRI is an integrity attribute on a script tag, holding a hash of the file's expected contents. The browser hashes what it fetched, and runs it only on a match. Trust moves from the address to the contents. That's real integrity assurance. If a CDN is compromised, the hash stops matching and the script doesn't run. It works well for your own static assets, pinned library versions, and anything with a build step. Third-party tags are different. Analytics, tag managers, chat widgets and payment SDKs change whenever the vendor ships. The next deploy breaks your hash, the browser refuses the script, and the feature it powers silently stops. There's no warning-only mode, so on your checkout that's an outage caused by your own security control. Scripts a third party injects at runtime are out of reach. And SRI can't help if a script was malicious when you hashed it. That's why almost nobody runs SRI on third-party tags in production, and why 6.4.3 says assure the integrity, not use SRI. Payload pinning keeps the idea and drops the breakage. Record the payload hash of every script observed in production. When a vendor ships new code, it comes back for review instead of breaking the page. An update becomes a decision, not an incident. And SRI isn't a replacement for a CSP. A CSP controls which origins may load resources. SRI checks a file is the one you expected. Run both where practical. Script Monitoring pins approval to the payload hash, and builds the inventory and justifications into a weekly evidence pack. Script Monitoring is free for 1,000 page views a month, with 6.4.3 & 11.6.1 included. Pro starts at $99 a month. Start for free at scriptmonitoring.com.