Subresource Integrity (SRI): Secure Third-Party Scripts

<p>Subresource Integrity (SRI) is a browser feature that lets you pin the exact cryptographic hash of a script or stylesheet you load from a CDN or third party. Add an <code>integrity</code> attribute to the tag, and the browser verifies the fetched file against that hash before executing it — if the content differs by even one byte, the browser refuses to run it and reports the violation. It converts &quot;we hope our CDN is never compromised&quot; into &quot;a compromised CDN cannot run altered code on our users.&quot;</p> <h2>The Threat Model</h2> <p>When you load <code>https://cdn.example.com/library.js</code>, you extend full JavaScript trust to whoever controls that domain, their registrar, their hosting, and every network hop in between. A single compromise anywhere in that chain — vendor breach, poisoned release, BGP hijack, malicious insider — executes arbitrary code on every page you serve: credential harvesting, session theft, crypto-clipboard hijacking, silentMage-skimming card data from checkout pages. The 2018 ticket-skimming attack on a major airline's payment page ran through exactly this vector, a third-party script that quietly changed.</p> <h2>Step 1: Generate the Hash</h2> <p>Hash the exact file you intend to ship, in the exact version you pinned:</p> <pre><code>curl -s https://cdn.example.com/[email protected] | openssl dgst -sha384 -binary | openssl base64 -A </code></pre> <p>The algorithm choices are sha256, sha384 (recommended) and sha512. You can also generate hashes with the SRI hash generator at srihash.org.</p> <h2>Step 2: Pin It on the Tag</h2> <pre><code class="language-html">&lt;script src=&quot;https://cdn.example.com/[email protected]&quot; integrity=&quot;sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC&quot; crossorigin=&quot;anonymous&quot;&gt;&lt;/script&gt; </code></pre> <p>Two rules the spec enforces: <code>crossorigin</code> must be present (even for same-origin-eligible resources it changes the fetch mode), and the hash format is <code>sha384-&lt;base64&gt;</code>. Pin the version in the URL too — an <code>integrity</code> attribute on a &quot;latest&quot; URL breaks the moment the vendor ships a new release, which is precisely the point.</p> <h2>Step 3: Know the Limits and Layer Accordingly</h2> <p>SRI verifies bytes, not behavior. It protects against <em>changes</em> to the file you pinned, not against a malicious-but-honest hash at pin time, and not against scripts that load additional scripts dynamically (those children are unpinned). Layer defenses:</p> <ul> <li>Pin every static third-party script you load — analytics, fonts, widgets, tag-manager bootstraps</li> <li>Add a <a href="https://2mny.com/kb/csp-configuration-guide">Content-Security-Policy</a> that whitelists script sources, so even an unpinned injection has nowhere to load from</li> <li>Review the third parties you load at all — every script is a permanent privileged tenant; the cheapest supply-chain fix is deletion</li> </ul> <h2>Step 4: Monitor for Breakage</h2> <p>When a pinned script's content changes, users get a console error and the script does not run — your site may visibly break (missing widget, lost analytics). That is the feature working. Route CSP report-uri / report-to violations to a log, and treat a spike of SRI failures on a pinned version as a supply-chain incident signal, not an inconvenience.</p> <h2>How 2MNY Checks This</h2> <p>Our scanner inventories the third-party scripts your pages load and reports which ones ship with <code>integrity</code> attributes — the gap list is usually 100% on first scan. The same report covers the CSP that bounds what unpinned scripts could do. Start a <a href="https://2mny.com/free-security-scan">free scan</a> to get your inventory; the fix per script takes about a minute.</p> <h2>Frequently Asked Questions</h2> <h3>Q: Does SRI protect against XSS on my own site?</h3> <p>A: No. SRI only guards files loaded from a URL with a pinned hash. An attacker injecting an inline script or a script from an arbitrary origin is CSP's job (script-src with nonces) plus output encoding. SRI is specifically the supply-chain control for files you intentionally load from others.</p> <h3>Q: What happens when the CDN serves a legitimately updated file?</h3> <p>A: The browser blocks it and your page loses that script until you update the hash. That is the designed behavior — no code change ships to your users without you pinning a new hash. Pin exact versions, and treat hash updates as deliberate release steps.</p> <h3>Q: Can I use SRI with my own self-hosted scripts?</h3> <p>A: You can, but it adds little: an attacker who can modify files on your origin can modify the HTML tag and its hash together. SRI's value is specifically when the HTML is yours but the script is someone else's.</p> <h3>Q: Which hash algorithm should I use?</h3> <p>A: sha384 is the practical recommendation — strong, universally supported in browsers that support SRI, and the default in most tooling. sha512 is equally valid; sha256 is fine but offers no advantage over the larger digests.</p>