Subresource Integrity is a small feature that solves a specific, common way checkouts get skimmed: a third-party script you deliberately load is quietly changed at its source. You did nothing wrong, your own site was not touched, but the file your customers download is no longer the file you approved. SRI lets the browser check, on every load, that the file it received is exactly the one you expected, and refuse to run it if it is not.
How it works
When you add a script to a page you name where it lives. With SRI you also record a cryptographic hash of the file’s contents, in an integrity attribute on the tag. The browser downloads the file, hashes what it received, and compares. If the two match, the script runs. If a single byte has changed, the hash will not match, and the browser discards the file rather than executing it.
A tag with integrity looks like this in shape: the source, then integrity="sha384-..." holding the hash, then crossorigin="anonymous" so the check is allowed to happen on a file from another origin. You generate the hash once from the exact file you intend to ship. Anyone can produce one from a file at the command line, and most CDNs publish the correct value alongside the library.
Why it matters for skimming
The supply-chain route into a checkout is the one you cannot patch away. Your platform is up to date, your admin accounts have multi-factor authentication, and you are still exposed, because a chat widget or an analytics library you load has been compromised at the vendor. When that happens, the vendor serves altered code to every site that embeds it. SRI breaks that chain: the altered file no longer matches the hash you pinned, so it does not run on your page, and your customers are protected even though the vendor is not.
This is exactly how the Ticketmaster breach happened, and exactly the class of attack SRI is built to stop. It is the natural partner to a Content Security Policy: the policy controls which origins may load and connect, SRI freezes the specific files so a trusted origin cannot serve you something new.
The catch, and how to live with it
SRI’s strength is also its limitation: it pins one exact file. That works beautifully for a library at a fixed version. It does not work for a script the vendor updates on their own schedule, because a legitimate update also changes the hash and the browser will then block the good new file along with the bad. This is why SRI suits versioned libraries and static assets, and does not suit a tag manager or a script served from a URL whose contents change by design.
The honest conclusion from that is not to force SRI onto a constantly-changing script. It is to ask why a constantly-changing third-party script is on your payment page at all. If it can move to a less sensitive page, move it. If it genuinely must load at checkout, it belongs on the short list you monitor most closely, and hosted payment fields become the real answer, because they put the card inputs somewhere that script cannot reach.
For everything you can pin, pin it. Pin your own bundled scripts, so a compromise of your file host is caught. Pin the fixed-version libraries you pull from a CDN. Each one you pin is a door that a supply-chain attacker can no longer walk through unnoticed.
The short version
Subresource Integrity records the exact hash of a script and tells the browser to refuse the file if it has changed. It is the defence against a trusted supplier serving you altered code, the supply-chain route that patching cannot close. Pin every file that has a fixed version, keep it paired with a Content Security Policy, and for the scripts that change too often to pin, ask whether they belong on the payment page in the first place.