Supply chain
Subresource Integrity: the third-party script defence most sites skip.
Published 2026-05-11 · Last updated 2026-05-11 · Vantyris editorial
Most small business sites load five to twenty scripts from third-party CDNs: analytics, fonts, A/B testing, chat widgets, payment SDKs. Every one of those is a supply-chain risk: if the CDN gets compromised, your site executes whatever malicious code the attacker swaps in, in your visitors' browsers, under your domain. Subresource Integrity (SRI) is the one-line browser-level defence that closes this. It takes minutes to add and stops 100% of the attack class.
What this means for your business
- When your site loads a script from a third-party CDN, the browser fetches whatever the CDN returns and runs it. The browser has no way to know if the CDN has been compromised and is serving a different file today than it served yesterday.
- SRI fixes this. You add an `integrity` attribute to the script tag containing a cryptographic hash of the file's expected content. The browser computes the hash of what the CDN actually delivered and refuses to run it if they don't match.
- Real-world attack: in 2018, a single library on a popular CDN was compromised, and thousands of e-commerce sites that loaded it lost credit-card data to the injected skimmer. Sites with SRI on that script tag were unaffected; the browser refused to run the swapped file.
How to fix
Add an `integrity` attribute with an SHA-384 hash and `crossorigin="anonymous"` to every external script and stylesheet tag. Use the CDN's published hash, or compute one with `openssl`.
- List your external scripts. Open Chrome DevTools → Network → reload. Filter by JS + CSS. Note every domain that isn't yours. Common ones: cdnjs.cloudflare.com, jsdelivr.net, unpkg.com, fonts.googleapis.com, google-analytics.com, googletagmanager.com.
- Decide which scripts you control the version of. SRI requires the file at the URL never changes. That works for pinned-version URLs (cdn.example.com/library@1.2.3/dist.js). It does NOT work for unpinned URLs (cdn.example.com/library/latest/dist.js). And it does NOT work for dynamic scripts like Google Analytics (gtag.js), where Google updates the file regularly. Skip those.
- Generate or copy the SRI hash for each pinned script. Most CDNs publish SRI hashes on their official pages (cdnjs.cloudflare.com shows them next to the URL). Or compute locally: `curl -sL <url> | openssl dgst -sha384 -binary | openssl base64 -A`. Prefix with `sha384-`.
- Update each script and stylesheet tag. Add the attributes: `<script src="https://cdnjs.cloudflare.com/library@1.2.3/dist.js" integrity="sha384-<hash>" crossorigin="anonymous"></script>`. The `crossorigin` attribute is required for SRI to work cross-origin.
- Test in a staging environment first. If the hash is wrong, the browser refuses to load the script. Your site breaks silently for visitors. Verify in DevTools that no script is blocked before shipping to production.
Owner: Your developer. · Time: 15-30 minutes for a typical site with 5-10 external scripts.
Common gotchas
- SRI hashes are tied to specific file content. If the CDN re-encodes the file (compression algorithm change, whitespace change), the hash invalidates and your script stops loading. Pin to specific version URLs, not 'latest' URLs.
- Don't add SRI to dynamic scripts (Google Analytics, Stripe.js, Tag Manager). These intentionally update over time and SRI would break them.
- If you load a third-party widget that itself loads scripts, SRI on the wrapper doesn't protect the children. The CSP `script-src` directive is the only defence against arbitrary nested loads.
- Browsers that don't support SRI (IE, very old Safari) load the script normally without integrity checking. That's a fail-open behaviour, not fail-closed, which is the right choice but worth knowing.
How to verify the fix
Run a Vantyris scan; the Supply chain category lists every external script and flags ones without SRI. Or use Mozilla Observatory (observatory.mozilla.org), which has its own SRI check.
Cyber Essentials alignment
This finding informs the following UK NCSC Cyber Essentials control areas:
- A2. Secure configuration — devices and services hardened against the inherent default vulnerabilities.
- A3. Security update management — software supported, updated, and patched within 14 days for high-/critical-risk vulnerabilities.
Vantyris is not a CE certifying body. The mapping above is informational.
Common follow-up questions
Is SRI worth the effort for a small site?
Yes. The fix is one attribute per script tag, takes minutes, and protects against an entire attack class. Compared to most security work, it's high-leverage.
Should I host third-party scripts on my own server instead?
Sometimes. Self-hosting eliminates the CDN supply-chain risk entirely. The tradeoff: you lose the caching benefit (visitors who already loaded the script from the CDN on another site don't get it from cache on yours). For low-traffic sites, self-host. For traffic-sensitive sites, use SRI with the CDN.
What if the third party updates their script and breaks my site?
That's the cost-benefit of SRI. With SRI, you choose when to upgrade. Without it, the CDN can change the file under you any time. Most sites prefer the explicit upgrade.
References
- MDN: Subresource Integrity MDN
- W3C: SRI specification Vendor
- OWASP: third-party JavaScript management OWASP
Related explainers
- Content Security Policy: the header that stops most XSS attacks dead.
- HSTS: the security header that locks HTTPS on for good.
Want Vantyris to scan your domain for this and 80 other findings?
Free teaser scan, no card. Verified scan from €10 with the full workspace around it: workflow, score trend, three PDF layouts, share links, monitoring.
Vantyris editorial team · methodology v1.0.0