Do I need SRI on scripts I host myself?

No - SRI exists specifically for resources loaded from a third-party origin you don't control. A script served from your own domain doesn't need an integrity hash, since a compromise there is a different problem SRI can't solve anyway.

What happens if the hash doesn't match?

The browser refuses to execute the script (or apply the stylesheet) at all, and logs a console error. This is a hard fail by design - a mismatched hash means the file changed from what you expected, and running it anyway defeats the entire point.

Does SRI protect against a CDN going down, not just being compromised?

No - a CDN outage still breaks your page either way; SRI only decides whether to run a file that did load. Pairing SRI with a crossorigin attribute and a fallback loading strategy handles availability separately from integrity.

Do I have to regenerate the hash every time the third-party library updates?

Yes, and that's a real trade-off - pinning to a specific version with a hash means an update to that CDN URL (if the vendor ever changes the file at the same path) won't silently apply. Most vendors publish a new versioned URL per release specifically so this isn't an issue in practice.

How to Fix Missing Subresource Integrity (SRI)

A <script src="https://cdn.example.com/lib.js"> tag runs whatever that CDN serves, with full access to your page - your cookies, your DOM, your users' input. Subresource Integrity is the one line that lets the browser refuse to run it if that file ever changes.

For the background on why third-party scripts need integrity checks, see what is subresource integrity. This guide shows how to add it.

The Actual Risk

Every third-party script tag is a standing grant of code execution on your site to whoever controls that CDN or origin - not just at the moment you added the tag, but every single time a browser loads that URL. If that CDN is compromised, or a build pipeline pushes a bad update to a shared path, every site referencing it is affected simultaneously - this is exactly how several real supply-chain attacks against widely-used JS libraries have played out.

SRI closes that gap for the specific case where the file at a URL changes unexpectedly: you supply a cryptographic hash of the exact file you expect, and the browser refuses to execute anything that doesn't match it byte-for-byte.

How to Add SRI

1. Get the hash

Most CDNs (cdnjs, jsDelivr) publish the SRI hash alongside the script tag directly on their site. To generate one yourself:

terminalGenerate a SHA-384 integrity hash for a file

cat lib.js | openssl dgst -sha384 -binary | openssl base64 -A

2. Add integrity and crossorigin to the tag

index.htmlBoth attributes are required together

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

crossorigin is required alongside integrity - without it, the browser can't read the response to verify the hash at all, and silently skips the check.

3. Apply it to stylesheets too

index.htmlSRI works on <link> tags the same way

<link
  rel="stylesheet"
  href="https://cdn.example.com/styles.css"
  integrity="sha384-9aIt2nRpC12Uk9gS9baDl411NQApFmC26EwAOH8WgZl5MYYxFfc+NcPb1dKGj7Sk"
  crossorigin="anonymous"
/>

How Scanverra Detects This

Scanverra's security scan inspects every <script> tag loading from an external origin and flags any that has no integrity attribute, so you get a concrete list of which third-party resources are running without any tamper protection.