Subresource integrity

What it means

Subresource integrity, or SRI, lets a page say what a file should look like before it loads it. You add an integrity attribute to a script or stylesheet tag, holding a base64 hash (SHA-256, SHA-384 or SHA-512) of the expected content. The browser fetches the file, hashes it and runs it only if the two match. Nothing else on the page changes.

If a CDN is compromised or someone swaps the file, the hash no longer matches and the browser refuses it. For files on another host, the tag also needs the crossorigin attribute so the browser can check the content.

Why it matters

A third-party script runs with the same rights as your own. If it is changed at the source, every site that loads it runs the attacker's code, with your customers' sessions and the page's forms in reach. That is a supply chain attack, and payment-page skimmers have used this route.

SRI turns a silent swap into a blocked load and a visible error. That is a better failure than an unnoticed one. It does not make a third party trustworthy, but it makes sure you only run the version you reviewed.

How it shows up

You meet it on script and link tags that point to a CDN, and in build tools that add hashes for you. You must update the hash when you update the file, so it suits versioned files that never change. A URL that serves different code over time will break the page.

Mistakes: no hash on tags that need one, a hash that is never updated, a missing crossorigin so the check fails, and scripts that load further scripts which SRI does not cover. It is also no help for tag managers, which change by design. For those, use a content security policy and review changes.