Subresource Integrity (SRI): Ensuring the Integrity of External Resources
Every modern website depends on other people’s code. Frameworks, analytics scripts, chat widgets, fonts, icons, A/B testing tools — they all come from somewhere else. That’s not a bad thing; it’s how the web works. But it also means that a big part of your site’s security depends on servers you don’t control.
That’s where Subresource Integrity (SRI) comes in. It’s a browser feature that makes sure the external files you load — like JavaScript or CSS — haven’t been changed behind your back. If the file has been tampered with, even by one character, the browser blocks it.
In other words, SRI is a simple but powerful way to protect your users from a compromised CDN, a hacked dependency, or an injected script that’s pretending to be legitimate.
The Problem SRI Solves
When a user visits your site, their browser doesn’t just talk to your domain. It talks to every domain that your page references. That might include content delivery networks, analytics providers, social media plugins, and more.
Every one of those requests is an implicit act of trust. You’re saying, “I trust this domain to send me safe code.” But what if that trust is misplaced?
History has plenty of examples. CDNs have been compromised and used to inject crypto miners. Popular JavaScript libraries were hijacked in supply chain attacks. Even ad networks have been used to distribute malware.
For CISOs, this isn’t just a technical problem; it’s a governance one. Every new third party on a site is another external dependency with its own risk profile. You can’t always control what happens on someone else’s infrastructure, but you can make sure that your users never execute anything that’s been modified.
That’s what SRI does. It verifies integrity at the browser level, before anything runs.
How It Works
SRI uses cryptographic hashes to confirm that a file’s contents are exactly what you expect. When you include a script or stylesheet, you add an integrity attribute with a hash of the file. The browser calculates its own hash when it downloads the resource and compares the two.
If the hashes match, the file runs. If not, the browser blocks it automatically.
A simple example looks like this:
<script src="https://cdn.example.com/lib.js" integrity="sha384-o0Rq4i..." crossorigin="anonymous"></script>
That long string is a SHA-384 hash of the exact version of lib.js that you tested. If the file changes — even a single space — the hash no longer matches, and the browser refuses to execute it.
You can generate these hashes easily with command line tools:
openssl dgst -sha384 -binary lib.js | openssl base64 -A
Or with npm:
npm run sri lib.js
It’s not complicated, but it’s effective. You’re adding a simple checksum that turns every third party request into a verifiable one.
Why It Matters
Without SRI, you’re trusting every external file completely. If a CDN is hacked, you’re hacked. If an ad script goes rogue, your users see the damage. With SRI, that same file would fail to load the moment it’s altered.
From a CISO’s point of view, SRI reduces the risk of supply chain attacks on the frontend — something that’s becoming more common as sites load more third party content. It’s a low-cost, high-impact control that turns an unverified dependency into a verified one.
SRI doesn’t rely on any external service or complex setup. It’s built right into the browser. And it works even when everything else fails.
SRI and CSP
SRI is even more powerful when paired with Content Security Policy (CSP). CSP tells the browser where code can come from. SRI makes sure that the code from those sources hasn’t been altered. Together they cover both origin and integrity — trust and verification.
Example setup:
Content-Security-Policy: script-src 'self' https://cdn.example.com
<script src="https://cdn.example.com/lib.js" integrity="sha384-o0Rq4i..." crossorigin="anonymous"></script>
CSP makes sure the script only loads from your CDN. SRI checks that the script is still the same one you approved. Even if the CDN itself gets compromised, the browser will block the tampered file.
For organizations already rolling out CSP, adding SRI is the natural next step. It’s the missing piece that locks down external scripts completely.
Implementation Challenges
SRI is simple in concept but can be tricky in practice. The main challenge is updates. Each time a file changes, the hash changes too. If you use versioned links like lib.js?v=2.3.1, you’ll need to regenerate the hash for each new version.
This isn’t a dealbreaker — you can automate it. Most build tools can generate and inject SRI hashes automatically as part of your deployment pipeline.
Another issue is dynamic third party content. Scripts that change on purpose, like A/B testing tools or analytics tags, can’t use SRI because the hash won’t stay the same. In those cases, you’ll need to rely on CSP and regular monitoring.
Also, SRI only works over HTTPS. That’s fine for modern sites, but something to note if you’re dealing with legacy environments.
What It Means for CISOs
For security leaders, SRI is one of those rare controls that improves security without adding complexity. It costs nothing to use, has no performance impact, and requires no new infrastructure.
It’s a way to bring real integrity to your third party supply chain — one that operates automatically in every user’s browser. In risk terms, it reduces the impact of a CDN or vendor compromise and limits the blast radius of any script injection attack.
In a world where JavaScript dependencies are often the weakest link, SRI is a small investment that pays off in resilience and trust.
Final Thoughts
Subresource Integrity isn’t flashy, but it represents what good web security should be: practical, built-in, and preventive. It doesn’t rely on expensive detection tools or human review. It just uses math to make sure what’s running in your users’ browsers is what you actually shipped.
Combine SRI with a solid Content Security Policy, and you have a strong line of defense against compromised third parties and supply chain attacks. It’s the kind of quiet control that won’t make headlines — but will keep you out of them.