OWASP Subresource Integrity (SRI) Guide: Securing the Supply Chain

Modern web applications are increasingly composed of third-party assets. From analytics and marketing trackers to UI frameworks and payment processors, the browser fetches code from dozens of external domains. While this modularity accelerates development, it creates a massive attack surface. If a Content Delivery Network (CDN) or a vendor's server is compromised, attackers can inject malicious payloads - such as credit card skimmers (Magecart) or credential harvesters - directly into your users' sessions.

Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources fetched from a CDN or any third-party server are delivered without unexpected manipulation. By providing a cryptographic hash of the expected file, you ensure that the browser only executes the code if it matches your known-good version.

Implementing SRI requires two primary attributes on your <script> or <link> tags: integrity and crossorigin. The integrity attribute contains the cryptographic hash, while the crossorigin attribute is mandatory for resources fetched from a different origin to allow the browser to check the hash without violating CORS policies.

A common reason for SRI failure is incorrect server-side configuration. Because SRI requires the crossorigin attribute, the remote server MUST return a valid Access-Control-Allow-Origin header. If this header is missing or does not include your domain, the browser will block the resource regardless of whether the hash matches.

The following table illustrates how SRI protects against common supply chain attack vectors compared to standard implementation.

Understanding what SRI does not do is as important as understanding its primary function. A common myth is that SRI replaces Vulnerability Scanning. It does not. SRI ensures you get the exact file you requested, but if that file itself contains a known vulnerability (like an old version of jQuery with an XSS bug), SRI will happily load it because the hash matches.

Another misconception is that SRI is only for JavaScript. It is equally important for CSS files, as malicious CSS can be used for data exfiltration via 'CSS Injection' or to perform UI redressing attacks.

The primary barrier to SRI adoption is the risk of a site breaking when a vendor updates their code. This is often referred to as the 'Secure but Broken' state. If you implement SRI on a file that the vendor updates without changing the URL, your site will stop working as the browser will block the new version due to the hash mismatch.

To manage this operational cost, version pinning is mandatory. You must never use URLs that point to 'latest.js' or unversioned paths. Always pin to a specific release (e.g., library-v2.1.0.js). This ensures that the file remains immutable and your hash stays valid until you choose to perform a manual update and re-hash of the asset.

SRI should not stand alone. It is most effective when paired with a robust Content Security Policy (CSP). While the experimental require-sri-for directive was originally proposed to mandate SRI, it has been deprecated and is not supported in modern browsers. Instead, security teams should focus on strict script-src and style-src directives to limit the domains that can serve code to your application.

In production environments, blocking a script due to an integrity failure can break critical user flows. To prevent this, elite engineering teams implement a 'Local Fallback' pattern. This involves attempting to load the script from a CDN with SRI, and if the object is missing (due to a hash mismatch), immediately loading a local, trusted copy of the same library.

SRI is designed for static assets. It should not be used for dynamic or session-based scripts. If a server generates a different JavaScript file for every user (e.g., including a personalized token in the source code), the hash will be different every time, and the integrity check will fail. In these cases, security should be managed through Subdomain Isolation or limited CSP scopes instead.