Technical
Subresource Integrity
Also called SRI.
Subresource Integrity is an `integrity` attribute on a `<script>` or `<link>` that holds a hash of the expected file, so the browser refuses to run it if the bytes differ.
How it is measured
The attribute looks like `integrity='sha384-oqVu...'` and goes with `crossorigin='anonymous'`. Generate the hash with `openssl dgst -sha384 -binary file.js | openssl base64 -A`, or copy it from the CDN's snippet. A mismatch blocks the file and logs an integrity error in the console.
Check that it works by changing one byte in a test copy and confirming the browser refuses it.
Worked example
A blog loads `chart.min.js` v4.4.1 from a public CDN with an SRI hash. The CDN account is compromised and the file is replaced with one that skims form fields. Every browser computes a different SHA-384 and blocks it, so charts stop rendering. The error appears on every visit that morning, and the team is alerted within 10 minutes.
Without SRI, those pages would have run the altered file for the hours until the provider noticed.
How it differs
Subresource Integrity checks file contents against a hash. CSP limits which origins may load at all. SRI catches a swapped file at a trusted host, and CSP stops loading from untrusted hosts. They work well together.
Common errors
Adding SRI to a file the CDN updates in place, which then breaks. Omitting `crossorigin`. Using it on a tag-manager container that changes constantly. Hashing the wrong build. Forgetting to update the hash when upgrading the version. Using an obsolete hash algorithm.
In practice
Pin third-party scripts to a version, add SRI hashes, and keep the hash in code next to the version. Skip it for files that legitimately change, and self-host those.