The third party risk
When you load a script from a content delivery network, you trust that server not to serve something malicious. If that server is compromised, every site that includes the script runs attacker code. Subresource integrity removes that blind trust by pinning the exact bytes you expect.
- You compute a hash of the known good file.
- You put that hash in the script tag integrity attribute.
- The browser refuses the file if the hash does not match.
How verification works
The browser downloads the resource, hashes it, and compares against the value you declared. A single changed byte produces a different hash, so a tampered or swapped file is rejected and never executes. You usually pair this with a crossorigin attribute so the fetch can be checked.
- Use a strong hash such as the sha384 family.
- Update the hash whenever you intentionally change the file.
- Combine with a content security policy for require integrity.
Integrity protects against a compromised delivery server, not against a malicious original author.
Key idea
Subresource integrity pins a cryptographic hash on a third party script so the browser refuses any file whose bytes do not match.