Frontend Beauty
ESC

Type to search the knowledge base.

Subresource Integrity

SRI hashes on script/link tags so CDN tampering fails closed; generate integrity and pair with CSP.

intermediate3 min read
  • security
  • sri
  • cdn
  • csp
  • supply-chain

Subresource Integrity (SRI) pins a cryptographic hash on third-party (or first-party) scripts and stylesheets. If the bytes change — CDN compromise, MITM on a bad network path, accidental swap — the browser refuses to execute/apply them.

Docs: MDN SRI, W3C SRI, web.dev SRI (related ecosystem).

Markup

<script
  src="https://cdn.example.com/lib-3.2.1.min.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"
></script>

<link
  rel="stylesheet"
  href="https://cdn.example.com/lib-3.2.1.min.css"
  integrity="sha384-..."
  crossorigin="anonymous"
/>

crossorigin="anonymous" is required so the browser can read the response for integrity checking under CORS rules for cross-origin resources.

Generate hashes

openssl dgst -sha384 -binary lib.min.js | openssl base64 -A
# → sha384-<base64>

Or shasum / build plugins that emit integrity in HTML.

When SRI fits

Good Awkward
Versioned CDN URLs Continuously mutating “latest” endpoints
Released static widgets Personalized JS per request
Known vendor versions Streaming random bundles

If the CDN URL content changes without URL change, SRI will break your site — that’s the feature. Pin versions.

CSP pairing

Content-Security-Policy: script-src 'self' https://cdn.example.com 'sha384-...'

SRI protects integrity of a specific file; CSP protects where scripts may load from. Use both — CSP.

Limitations

  • Doesn’t help if your build already baked malware in.
  • Doesn’t validate API JSON responses.
  • Inline scripts use CSP nonces/hashes, not SRI attributes.
  • Attackers who can change your HTML can change the integrity hash too — protect HTML origin and deploy pipeline.

Interview out-loud

“SRI pins sha384/sha512 of a script or stylesheet; mismatched bytes won’t run. I use it for versioned CDN assets with crossorigin anonymous, and pair with CSP. Don’t SRI a floating latest URL.”

Reviewer prompts

  • What is the asset (session, PII, money movement)?
  • What is the attacker capability (web, XSS, network, dependency)?
  • Which control fails closed if misconfigured?
  • Is the server still enforcing authz?
  • Any new third party, iframe, or URL sink?

Residual risk note

Browser controls reduce likelihood and impact; they do not eliminate bugs. Prefer defense in depth: safe defaults in code, strict headers, and monitoring (CSP reports, auth anomaly alerts). When product pressure weakens a control, write down the accepted risk and a revisit date.

Automation

Generate integrity hashes in the build that produces your HTML includes, or use a bundler plugin when injecting CDN tags. When upgrading a library, the hash must change in the same PR as the version bump — otherwise you either break production or accidentally deploy without SRI. Snapshot the integrity strings in code review diffs so they are not rubber-stamped.

Further depth

Teams often under-invest in this topic until an incident or CWV regression. Schedule a one-hour drill: reproduce the failure mode in DevTools, list the top three mitigations for your stack, and file tickets with owners. Revisit after the next major feature that touches networking, rendering, auth, or third parties — those are the moments regressions land. Keep primary documentation links in the runbook so on-call is not searching chat history at 2am.

Concrete artifacts to leave behind: a short architecture note, a CI assertion or header snapshot, and a dashboard panel (lab or field) that would have caught the last bug. Teaching the rest of the team the mental model matters as much as the one-line fix.

Further reading

Related guides