Subresource Integrity: Verifying Third-Party Scripts

How a simple cryptographic hash lets browsers detect if a third-party script has been tampered with.

Core Concept

Subresource Integrity (SRI) lets a page specify a cryptographic hash for an externally loaded script or stylesheet, and the browser refuses to execute the resource if its content doesn't match.

This directly addresses the risk of a compromised third-party CDN or hosting provider silently serving malicious content to every site that references it.

Insight: SRI shifts trust from 'this CDN will always serve what I expect' to 'the browser will verify exactly what it receives against a known-good hash.'

How SRI Verification Works

The mechanism relies on a hash attribute added directly to the script or link tag.

A cryptographic hash of the expected file content is included in the integrity attribute
The browser computes the hash of the actually downloaded resource
A mismatch causes the browser to refuse to execute or apply the resource

Fail-Safe by Design

SRI fails closed — if the hash doesn't match, the browser blocks the resource entirely rather than loading a potentially tampered version.

Why Third-Party CDN Compromise Is a Real Risk

Widely used CDN-hosted libraries represent an attractive, high-leverage target for attackers.

A single compromised CDN can affect every site loading from it simultaneously
Supply-chain attacks specifically targeting popular hosted libraries
Difficult for individual sites to detect a CDN-side compromise on their own

Limitation: Without SRI, a site has no way to detect that a trusted third-party CDN has begun serving subtly modified, malicious content.

SRI Maintenance Considerations

Using SRI does introduce a maintenance requirement that needs to be handled correctly.

Whenever the referenced third-party file legitimately updates, the corresponding hash must also be updated, or the resource will simply fail to load.

Hash Must Track Updates

Pinning a hash without a process to update it when the upstream resource changes turns SRI into an availability risk rather than a security improvement.

Combining SRI With CSP

SRI and Content-Security-Policy complement each other well as layered defenses.

CSP restricts which origins scripts can load from at all
SRI verifies the actual content of what's loaded from those origins
Together they address both source trust and content integrity

Insight: CSP answers 'is this source allowed at all,' while SRI answers 'is this exact content what I expected' — the two work best deployed together.

Real-World Implementation

SRI is widely recommended for any externally hosted script or stylesheet dependency.

Popular CDN providers publishing SRI hashes alongside their libraries
Build tools automatically generating and updating SRI hashes
Security audits flagging third-party scripts loaded without SRI

For any site relying on externally hosted JavaScript or CSS, SRI closes a meaningful supply-chain risk with a relatively small implementation cost.

Common Mistakes to Avoid

A few common mistakes undermine the reliability of Subresource Integrity.

Pinning a hash without a process to update it when the referenced file legitimately changes.
Assuming SRI alone is sufficient without also restricting sources through CSP.
Overlooking SRI for third-party scripts loaded from less common or self-managed CDNs.
Failing to verify the SRI hash actually matches the current version of a resource.
Treating a broken SRI hash as an availability failure rather than investigating it.
Overlooking that SRI hashes need updating whenever the referenced library version changes.
Assuming SRI applies automatically to all script tags without explicit configuration.
Failing to generate SRI hashes for self-hosted, not just CDN-hosted, resources.
Overlooking that build tools can automate SRI hash generation to reduce manual error.
Assuming SRI protects against a CDN going offline, not just content tampering.
Failing to plan for what happens if an SRI hash mismatch actually occurs in production.
Overlooking that dynamically injected scripts require special handling for SRI to apply correctly.

Best Practices Checklist

These practices help keep SRI protection reliable and up to date.

Establish a clear process to update SRI hashes whenever a referenced resource changes.
Combine SRI with CSP to control both resource origin and content integrity together.
Use build tools to automatically generate and update SRI hashes where possible.
Apply SRI consistently across all externally hosted scripts and stylesheets, not just some.
Investigate any SRI mismatch as a potential integrity issue rather than dismissing it.
Establish a clear process for updating SRI hashes alongside library version updates.
Explicitly add integrity attributes to every relevant script and stylesheet tag.
Consider applying SRI to self-hosted critical resources as well as CDN-hosted ones.
Use build tool automation to generate and update SRI hashes, reducing manual maintenance error.
Understand that SRI protects against tampering specifically, not against CDN availability issues.
Plan a fallback strategy for what happens if an SRI mismatch blocks a critical resource in production.
Apply SRI attributes correctly even for scripts injected dynamically via JavaScript.

Frequently Asked Questions

Frequently asked questions about Subresource Integrity.

What does Subresource Integrity actually protect against?

It protects against a compromised third-party CDN or hosting provider silently serving modified, potentially malicious content to every site that references it.

What happens if the SRI hash doesn't match the downloaded resource?

The browser refuses to execute or apply the resource entirely, failing closed rather than loading a potentially tampered version.

Does SRI require ongoing maintenance?

Yes — whenever a referenced third-party file legitimately updates, its corresponding hash must also be updated, or the resource will fail to load.

How does SRI complement Content-Security-Policy?

CSP restricts which origins scripts can load from at all, while SRI verifies the actual content of what's loaded from those origins.

Do popular CDN-hosted libraries provide SRI hashes?

Many do — popular CDN providers commonly publish SRI hashes alongside their libraries specifically to support this practice.

What happens if an SRI hash isn't updated after a library version change?

The resource fails to load entirely, since the browser detects the content no longer matches the pinned hash.

Is SRI applied automatically once enabled somewhere on a site?

No — it must be explicitly added to each individual script or stylesheet tag; there's no site-wide automatic application.

Should SRI be used for self-hosted resources too?

It can add value even for self-hosted critical resources, protecting against tampering anywhere along the delivery path.

Can SRI hash generation be automated?

Yes — many modern build tools automatically generate and update SRI hashes as part of the build process, reducing manual maintenance burden.

Does SRI protect against a CDN outage?

No — it protects against tampered content specifically; a CDN outage is a separate availability concern requiring its own fallback strategy.

Does SRI work for dynamically injected scripts?

Yes, but it requires setting the integrity attribute programmatically at injection time rather than relying on static HTML markup alone.

Check Subresource Integrity Usage

Run a security headers scan to see whether third-party resources use Subresource Integrity.

Launch Tool →