Skip to content

Security

How to add subresource integrity to third-party scripts

A script loaded from someone else's origin runs with full access to your page, and you find out it changed when your users do. An integrity hash makes the browser refuse to execute a file that no longer matches what you pinned.

What 13x checks

This is rule security.sri in the public registry: Third-party scripts pinned with integrity. It runs on every audit, against the pages we actually fetched, and its result is derived from the response rather than estimated.

Surface
Security
Score weight
4 of the readiness score
Scope
Runs on every audited page
Applies
To every site

Registry version 2026-07-30. Every rule is published, and the audit is deterministic — the same page produces the same finding every time.

The fix

The same text the audit hands you when this check fails on your own site.

Third-party scripts loading without an integrity hash: .

Pin them so the browser refuses a file that has changed:

html code
<script
  src="https://cdn.example.com/library@1.2.3/dist/library.min.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"
></script>

Generate the hash:

bash code
curl -s https://cdn.example.com/library.js | openssl dgst -sha384 -binary | openssl base64 -A

The limitation worth knowing: SRI only works for a file that never changes. A tag manager, an analytics loader or anything on a @latest URL updates itself, so it cannot be pinned — which is the argument for self-hosting those instead. Note that whoever controls that CDN path can currently run any code they like with full access to your users' sessions.

Does your site have this problem?

13x checks this and 112 others against your live URL in about 30 seconds. No account, and every finding comes with the fix for your framework.

No signup. Results in 30 seconds.

More security checks