← Glossary

Network & Infrastructure

SRI (Subresource Integrity)

Also: Subresource Integrity · integrity attribute · sha384 integrity · CDN integrity

Last reviewed:

In one sentence

SRI (Subresource Integrity) is an HTML attribute that lets the browser verify a script or stylesheet loaded from a third party — a CDN — has not been altered, by checking it against a cryptographic hash you embed in the tag.

Why it matters

If your site loads a library from a CDN and that CDN is compromised — or its account is, or the file is simply replaced by a different version — every visitor silently gets whatever is served now: no error, no warning. That is the shape of the 2018 British Airways breach and of every Magecart-style card skimmer, and the reason PCI DSS v4 requirement 6.4.3 wants every payment-page script authorised and integrity-checked. With an integrity attribute in place, the browser refuses to execute a resource whose hash does not match, turning a silent supply-chain compromise into a loud, visible failure.

How it looks, and what it cannot do

<script src="https://cdn.example/lib/4.2.0/library.min.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>
  • The value is algorithm-base64 digest; sha384 is the convention, sha256 and sha512 are accepted, and several may be listed space-separated (the browser uses the strongest it supports).
  • crossorigin="anonymous" is required for cross-origin resources, and the CDN must send Access-Control-Allow-Origin, or the browser cannot read the bytes to hash them and blocks the load.
  • It applies to <script> and <link rel="stylesheet"> (and to fetch() via the integrity option). Not to images, fonts, iframes, or anything a script loads later.
  • It only works for static, versioned files. A URL that serves "latest" will break the moment the file changes — which is the intended behaviour, and why you pin the version in the URL.
  • It does not help when the attacker controls your own HTML: they simply change the hash too. That is what CSP, and a clean deployment pipeline, are for.

Try it yourself hands-on

Adding integrity protection to a third-party script your checkout page loads:

  1. Open the SRI Hash Generator and give it the asset's URL (pinned to a version), or paste the file's content. It computes the sha256/sha384/sha512 digests and emits the complete <script> tag with integrity and crossorigin set.
  2. Put the tag in your page exactly as output. Load the page: if the CDN's CORS headers are missing, the console says so and the script is blocked — fix that before shipping, or self-host the file instead (which removes the third party altogether and is often the better answer).
  3. Understand the failure mode you just bought: when the CDN updates the file at that URL, the load breaks. That is correct — you will notice, look at the diff, regenerate the hash for the version you have reviewed, and ship it deliberately.
  4. Pair it with a policy. In the CSP Builder, restrict script-src to the sources you allow; SRI verifies the integrity of an allowed file, CSP decides which sources are allowed at all. The HTTP Security Headers Grader tells you whether the policy actually reached production.

Common misreadings

  • SRI is not a substitute for reviewing the library. It guarantees you got the file you hashed, not that the file is safe.
  • Self-hosting is often simpler. If you must review every version anyway, serving the file yourself under your CSP removes the CDN risk and the CORS dance.
  • Dynamic loaders bypass it. A script that injects further <script> tags at runtime loads them without integrity unless it sets the attribute itself.