Verifiedapp Blog
Security Headers

Subresource Integrity (SRI): trusting the CDN you do not control

· 3 min read
#cdn#security-headers#sri#supply-chain

The trust you give away with every CDN tag

Most sites load some code they do not host themselves — a library from a CDN, an analytics script, a font or widget from a third party. Every one of those tags is an act of trust: you are telling the browser to download whatever that server sends and run it with full access to your page. If that server is compromised, or the file is swapped, your visitors execute the attacker's code and you may never see it happen.

Subresource Integrity is how you replace that blind trust with verification.

How SRI works

SRI adds an integrity attribute to your <script> or <link> tag. It holds a cryptographic hash — a fingerprint — of the exact file you expect:

  • <script src='https://cdn.example/lib.js' integrity='sha384-...' crossorigin='anonymous'></script>

When the browser fetches the file, it hashes the bytes it received and compares them to the hash you provided. If they match, the file runs. If they do not — because the file changed, by attack or otherwise — the browser refuses to execute it. There is no way for tampered content to slip through, because the fingerprint will not line up.

The crossorigin='anonymous' part is needed so the browser can read the cross-origin response to check it.

What SRI protects against

  • A compromised CDN or third-party host quietly serving altered code.
  • A hijacked or expired domain that someone else now controls and serves scripts from.
  • An accidental change to a file you assumed was frozen at a version.

It is a precise control: it does not stop the file from being requested, it stops a changed file from running.

Where SRI fits — and where it does not

SRI works best on resources pinned to a specific version, where the file is not supposed to change. That is exactly the case for a library loaded at a fixed version from a CDN.

It is a poor fit for resources that are meant to update on the server's schedule — many analytics or tag-manager scripts deliberately change, and a fixed hash would break them on every update. For those, SRI is not the right tool, and you lean on other controls like a strict Content-Security-Policy and minimising third-party scripts in the first place.

SRI and CSP complement each other: CSP controls where scripts may load from, SRI verifies that a specific file was not altered.

How to add it

  • Generate the hash for each pinned external file (most CDNs publish the integrity value, or you can compute a SHA-384 yourself).
  • Add the integrity and crossorigin attributes to the tag.
  • Update the hash whenever you intentionally bump the version — a changed file requires a changed fingerprint.

Check your third-party scripts

It is easy to lose track of which external scripts your pages load and which are protected. An automated scan inventories the third-party resources your site pulls in and flags externally hosted scripts that run without integrity checks. Scan your site and see where you are trusting a CDN on faith.

Related reading

FAQ

What does the integrity attribute actually do?
It holds a cryptographic hash of the file you expect. The browser hashes the resource it downloads and compares; if the file was altered, the hashes will not match and the browser refuses to run it. Tampered code simply cannot execute.
Should I add SRI to every external script?
Add it to resources pinned to a fixed version that are not supposed to change — that is where it shines. Skip it for scripts designed to update on the server's schedule, like some analytics tags, since a fixed hash would break them on every update.
Does SRI replace a Content-Security-Policy?
No, they do different jobs and work well together. CSP controls which origins scripts may load from, while SRI verifies that a specific file was not altered. Use both: CSP for where, SRI for whether the file is intact.

Keep reading