Subresource Integrity: what SRI solves and what breaks
The right idea with a practical problem: SRI pins file contents by hash, and third-party vendors update their files without telling you.
TL;DR
Subresource Integrity
WHAT IT IS
An integrity attribute on a script or link tag containing a hash of the file's expected contents. The browser refuses to execute a file that does not match.
WHAT IT SOLVES
A compromised CDN or altered file. Exactly the integrity assurance PCI DSS 6.4.3 asks for.
WHY IT IS RARE ON TAGS
Third parties update their scripts without notice, and every update breaks the hash, which means the script stops loading.
Short on time? SRI is the right idea. Pinning the observed payload achieves it without the breakage.
What is Subresource Integrity?
Subresource Integrity is a browser feature that lets you specify a cryptographic hash of a script or stylesheet, so the browser will refuse to execute the file if its contents do not match that hash. It is implemented with an integrity attribute on the script tag and is one of the more elegant security features in the platform: it shifts trust from the address a file came from to the contents of the file itself. If a CDN is compromised and serves altered JavaScript, the hash no longer matches and the browser refuses to run it, with no action required from you.
Blocking by hash pins the exact payload you approved, so a vendor that ships new code has to be re-approved rather than silently inherited.
How SRI works
<script src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>The browser fetches the file, hashes the contents, compares against the attribute, and executes only on a match. Any change to the file, malicious or legitimate, produces a mismatch and the script does not run.
Where SRI works well
Your own static assets on a CDN. You control the release cycle, so you update the hash when you update the file. This is the ideal case.
Pinned library versions. A specific version of a library at a versioned, immutable URL. The file should never change, and if it does you want to know.
Anything with a build step. If a build generates your markup, generating the hash alongside it is straightforward.
Pinning the observed payload gets the integrity assurance without the breakage.
Why it breaks on third-party tags
Analytics, tag managers, chat widgets and payment SDKs are served from URLs whose contents change whenever the vendor ships. That is deliberate: it is how they deploy fixes without asking every customer to update a tag.
Add SRI to one of those and the next vendor deploy produces a hash mismatch, so the browser refuses to run the script and the feature it powers silently stops working. If that script is on your checkout, you now have an outage caused by your own security control. Which is why almost nobody runs SRI on third-party tags in production, and why 6.4.3 says 'assure the integrity' rather than 'use SRI'.
Achieving the same goal without the breakage
The insight behind SRI is correct: trust the contents, not the address. The problem is enforcing it in markup you have to update by hand.
Recording the payload hash of every script observed in production achieves the same integrity assurance without the fragility. When a vendor ships new code, the change is detected and surfaced for review rather than silently breaking the page. You keep the assurance, and a vendor update becomes a decision instead of an incident.
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
Partly. It addresses the integrity assurance element well, for the scripts you can apply it to. It does not produce the inventory or the written business justification per script, which are the other two elements of the requirement.
This is the central practical problem: the vendor changes the file contents whenever they deploy, without notifying you. The next deploy breaks your hash and the script stops loading.
The browser refuses to execute the resource entirely. There is no warning-only mode and no partial execution. On a payment page that can mean a broken checkout.
Sha384 is the common choice and sha256 and sha512 are also supported. You can supply multiple hashes, and the browser accepts the resource if any one matches, which is useful during a planned transition.
Partly. The integrity property can be set when creating a script element programmatically, and any script injected by a third party at runtime is outside your control entirely, which is where most of the risk sits.
Yes, for cross-origin resources. Without it the browser cannot read the response to verify it, and the resource is blocked.
No, they answer different questions. A CSP controls which origins may load resources. SRI verifies that a specific file is the file you expected. Running both is sensible where both are practical.
Partly, and we would be careful. Payment SDKs update, sometimes urgently for security reasons, and a hash mismatch means your payment form stops working. Most providers advise against pinning their SDK.
Record the payload hash observed in production and treat a change as a review item rather than a block. You get the integrity assurance 6.4.3 asks for, and a vendor update becomes a decision instead of an outage.
Partly. It protects against the file changing after you pinned it, which covers a compromised CDN. It does nothing about a vendor whose script was malicious at the moment you generated the hash.
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
CSP vs script monitoring: two controls, different jobs
One governs where scripts come from. The other governs what they do. You want both.
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.