Integrity violations

This page lists scripts that loaded without valid Subresource Integrity (SRI) metadata, or with metadata that did not match. Each row is a script whose content nobody verified.

Each script is listed with the document origin that loaded it, the browsers that reported it, and its disposition:

Columns

The report table has these columns:

Drilling in adds Destination, which tells you what the browser was fetching the resource as.

The fix

Add an integrity attribute with the correct hash, plus crossorigin so the browser can verify it:

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

Generate hashes at build time. Hand-maintained integrity attributes go stale on the next vendor update and turn into outages, which is the usual reason teams abandon SRI after trying it.

For a one-off value, the SRI generator computes the hash from a script or stylesheet URL. It also checks the CORS headers verification needs, which is the other half of why SRI silently fails.

Two cases the fix does not cover

A URL whose content changes on every request cannot carry a static hash. Pin it to a versioned URL first, then add integrity.

A vendor that will not publish stable versioned assets is a supply-chain decision, not a markup problem. Your options are hosting a copy yourself, dropping the dependency, or accepting unverified content and monitoring it through CSP hashes instead.

Overlap with CSP hashes

A script appearing on both pages is one you know is changing and have not pinned. CSP hashes records what everything hashed to. This page records where verification was expected and did not happen.

Next steps

• CSP hashes
• Integrity-Policy reference