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). Each one is a supply-chain risk. If the CDN is compromised, your site runs whatever malicious code the attacker swaps in, in your visitors' browsers, under your domain. Subresource Integrity (SRI) is a one-line defence, enforced by the browser, that closes this gap. 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. It has no way to know whether the CDN has been compromised and is serving a different file today than it served yesterday.
- SRI fixes this. You add an
integrityattribute to the script tag containing a cryptographic hash of the file's expected content. The browser hashes what the CDN actually delivered and refuses to run it if the two don't match. - This has happened. 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, because 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 and reload. Filter by JS + CSS and 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 only works if the file at the URL never changes. That holds for pinned-version URLs (
cdn.example.com/library@1.2.3/dist.js). It does NOT hold for unpinned URLs (cdn.example.com/library/latest/dist.js), or for dynamic scripts like Google Analytics (gtag.js), which Google updates 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 one locally with
curl -sL <url> | openssl dgst -sha384 -binary | openssl base64 -A, then prefix the result withsha384-. - 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>. Thecrossoriginattribute 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, and your site breaks silently for visitors. Check 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 exact file content. If the CDN re-encodes the file (a compression algorithm change, a whitespace change), the hash no longer matches 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). They update on purpose over time, and SRI would break them.
- If you load a third-party widget that loads scripts of its own, SRI on the wrapper doesn't protect the children. The CSP
script-srcdirective is the only defence against arbitrary nested loads. - Browsers that don't support SRI (IE, very old Safari) load the script normally, with no integrity check. That's fail-open rather than fail-closed. It's 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 the ones without SRI. Mozilla Observatory (observatory.mozilla.org) has its own SRI check too.
Cyber Essentials alignment
This finding informs the following Cyber Essentials control areas (the UK government's baseline scheme, a sound checklist in any country):
- A2. Secure configuration: devices and services hardened against the weaknesses they ship with by default.
- A3. Security update management: software stays in vendor support, and high or critical patches go on within 14 days.
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. It's one attribute per script tag and a few minutes of work, and it protects against an entire attack class. Next to most security work, it's worth doing first.
Should I host third-party scripts on my own server instead?
Sometimes. Self-hosting removes the CDN supply-chain risk entirely. The tradeoff is 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 at 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 check your domain for this and 196 other problems?
The teaser scan is free and needs no card. A verified scan starts at $10€10£10A$15¥1,500AED 40 and comes with the workspace: finding workflow, score trend, three PDF layouts, share links and monitoring.
Written by Vantyris