Add Subresource Integrity (SRI) to third-party scripts

30 min Impact: medium Effort: medium ✓ Scan-verified — no manual checkbox

Subresource Integrity lets you tell the browser exactly what a third-party script or stylesheet SHOULD contain (a cryptographic hash) — without it, if that third-party CDN is ever compromised, the malicious replacement script loads on your site with zero warning, running with full access to your page.

Loading a script from a CDN means trusting that CDN never gets compromised. An integrity attribute makes the browser verify the file matches an exact hash before running it — if the CDN is ever compromised, the script simply fails to load instead of running malicious code on your site.

The full picture

Subresource Integrity provides genuine, cryptographic verification that third-party scripts and stylesheets loaded from external sources haven't been tampered with between when you originally referenced them and when a visitor's browser actually loads them — this addresses a real, documented risk in relying on external, third-party-hosted resources.

The genuine vulnerability this protects against involves a scenario where a third-party service hosting a script or stylesheet you reference gets compromised, or where a content delivery network serving that resource is somehow compromised or intercepted — without SRI, your site would unknowingly load and execute whatever modified, potentially malicious content now exists at that external location.

The mechanism involves generating a cryptographic hash of the expected, legitimate resource content, then including that hash in your reference to the external resource — browsers verify the actually-loaded content matches this expected hash before executing it, refusing to load the resource at all if the content has been modified from what you originally verified and referenced.

This protection specifically matters for any third-party scripts your site includes, given that these represent genuine trust extended to external parties and infrastructure outside your direct control — implementing SRI for these external dependencies closes off the specific risk that a compromise anywhere in that external delivery chain could silently inject malicious code into your own pages.

How to fix it

1

Identify third-party scripts and stylesheets you load

Any <script> or <link> tag pointing to an external CDN (jQuery, analytics libraries, font services, ad tags).
2

Generate an integrity hash for each

Most CDNs (cdnjs, jsDelivr) provide the SRI hash directly alongside their embed code — copy it as given.
3

Add the integrity and crossorigin attributes

<script src="..." integrity="sha384-..." crossorigin="anonymous"> — the browser will refuse to run the script if its actual content doesn't match the hash.
4

Update hashes whenever you update the library version

A new version of a library has a different hash — SRI will correctly BLOCK it as "tampered" if you forget to update the hash alongside the version.

Common mistakes

If you forget to update the SRI hash when you update a library version, the browser will refuse to load the new (legitimate) version — this is a common self-inflicted breakage, not an attack.