Subresource Integrity (SRI)
Subresource Integrity is a browser security feature that verifies resources loaded from external sources (CDNs, third-party hosts) have not been tampered with, by comparing the resource content against a cryptographic hash embedded in the HTML.
Understanding Subresource Integrity (SRI)
When your application loads a JavaScript file from a CDN (e.g., <script src="https://cdn.example.com/library.js">), you are trusting that CDN to serve the correct file. If the CDN is compromised, the attacker can replace the library with malicious code that runs in every user's browser with full access to your application. SRI eliminates this trust by including a hash of the expected file content.
An SRI-enabled script tag looks like: <script src="https://cdn.example.com/library.js" integrity="sha384-abc123..." crossorigin="anonymous">. The browser downloads the file, computes its hash, and compares it to the integrity attribute. If they do not match, the browser refuses to execute the script. This means even if the CDN serves a modified file, your users are protected.
SRI supports SHA-256, SHA-384, and SHA-512 hash algorithms. You can include multiple hashes for the same resource (for migration during library updates). The crossorigin="anonymous" attribute is required for SRI to work on cross-origin resources, as the browser needs access to the raw response bytes for hashing.
SRI is most valuable for scripts loaded from third-party CDNs. It is less relevant for first-party resources served from your own domain (where a compromised server could modify both the HTML and the resource). However, it remains useful for resources served from a different infrastructure than your main application, like a dedicated CDN or static asset domain.
Why This Matters for Vibe-Coded Apps
Vibe-coded applications that load libraries from CDNs rather than bundling them (common in older setups or when an AI suggests CDN script tags) should use SRI to protect against CDN compromise. Modern bundlers (webpack, Vite, esbuild) bundle dependencies into your application, making SRI less relevant for those resources since they are served from your own domain.
If your AI-generated code includes <script> tags loading from external CDNs, add integrity attributes. Tools like srihash.org generate the correct hash values. Alternatively, consider bundling these dependencies instead of loading them from CDNs — this eliminates the third-party trust entirely.
Real-World Examples
British Airways Magecart via CDN Script
The British Airways breach involved attackers compromising a script loaded from a third-party CDN. Had SRI been implemented, the browser would have detected the modified script content and refused to execute it, preventing the credit card skimming attack entirely.
Polyfill.io Supply Chain Attack (2024)
After the polyfill.io domain was acquired by a new owner, the service began serving malicious code to hundreds of thousands of websites that loaded the polyfill script. Sites using SRI would have been protected because the hash mismatch would have blocked the modified script.
jQuery CDN Integrity
jQuery's official documentation includes SRI hashes for all CDN-hosted versions. This practice became an industry standard after researchers demonstrated how CDN compromise could affect millions of sites. When including jQuery from a CDN, the SRI hash ensures the exact expected version is loaded.
Frequently Asked Questions
Does SRI work with dynamically loaded scripts?
SRI works with any <script> or <link> tag that has an integrity attribute, including those added dynamically via JavaScript. However, if you use fetch() or XMLHttpRequest to load resources, SRI does not apply — the browser only checks integrity on <script> and <link> elements. For dynamically fetched resources, you would need to implement hash verification in your application code.
What happens when a library updates and the hash changes?
The browser will block the updated file because it no longer matches the pinned hash. This is both a security feature (preventing unauthorized changes) and an operational consideration (you must update the hash when you intentionally upgrade). If you use a versioned CDN URL (library@1.2.3), the content should not change and the hash remains valid. If you use a "latest" URL, SRI will break on every update — avoid this combination.
Is SRI necessary if I bundle all my dependencies?
If all your JavaScript is bundled and served from your own domain/CDN, SRI provides less benefit because a compromised server could modify both the HTML page and the script. SRI is most valuable when the HTML and the script are served from different infrastructure. However, using SRI on bundled resources still protects against CDN cache poisoning or intermediate proxy tampering if your assets are served from a different origin than your HTML.
Can SRI protect against all supply chain attacks?
SRI protects against supply chain attacks that modify already-deployed files on CDNs or delivery networks. It does not protect against malicious packages that are compromised at the source (before you generate the hash), development dependency attacks that execute during build, or attacks that modify your own build pipeline. SRI is one layer of supply chain defense, complementing dependency auditing and build pipeline security.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to subresource integrity (sri) and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan