Overview
Subresource Integrity (SRI) is a security feature that allows web developers to ensure that resources loaded from third-party origins, such as CDN-hosted JavaScript or CSS files, have not been tampered with. It works by specifying a cryptographic hash of the expected resource in the HTML tag that loads it. When the browser fetches the resource, it computes the hash of the downloaded content and compares it against the expected hash. If they do not match, the browser blocks the resource and does not execute it.
Developers typically implement SRI when including external libraries, scripts, or stylesheets from CDNs or other external sources. This is especially critical in environments where the integrity of third-party resources cannot be fully trusted. SRI is not a replacement for other security practices such as HTTPS or Content Security Policy (CSP), but it adds a crucial layer of protection against malicious or compromised resources.
Why It Matters
Subresource Integrity is essential in modern web development because it helps protect against supply chain attacks, where an attacker compromises a third-party service or CDN to inject malicious code into a resource that is then loaded by multiple websites. Without SRI, a compromised CDN could silently deliver harmful code to a site, and the site owner might not notice until it's too late.
In production environments, SRI prevents a class of attacks known as "malicious CDN injection" or "dependency hijacking," where attackers target popular open-source projects or CDNs to inject code that can steal cookies, redirect users, or perform other malicious actions. SRI ensures that even if an attacker gains control of a CDN, they cannot silently modify resources that are loaded with integrity checks.
How It Works
The mechanism of Subresource Integrity relies on cryptographic hashes to verify resource integrity. When a developer includes a resource using an HTML tag such as <script> or <link>, they can add an integrity attribute that contains a base64-encoded hash of the expected resource. The browser then downloads the resource and computes its own hash, comparing it to the one provided in the attribute.
- The
integrityattribute must contain a hash algorithm followed by a base64-encoded hash of the resource, in the format:hash-algorithm-hash. - Supported hash algorithms include SHA-256, SHA-384, and SHA-512. SHA-256 is the most commonly used due to its balance of security and performance.
- If the computed hash does not match the expected hash, the browser blocks the resource and fires a
securitypolicyviolationevent. - The integrity check is performed only for resources fetched over HTTPS or from the same origin. Resources loaded over HTTP are not validated.
- When SRI is enabled, browsers will not execute or render resources that fail the integrity check, even if the resource is otherwise valid.
Quick Reference
| Item | Purpose | Notes |
|---|---|---|
| integrity attribute | Specifies expected cryptographic hash of a resource | Must be present for SRI to be effective |
| hash-algorithm | Identifies the cryptographic algorithm used | SHA-256, SHA-384, SHA-512 supported |
| base64-encoded hash | Computed digest of the resource | Generated using the specified algorithm |
| cross-origin resource | Resource fetched from a different domain | SRI only applies to cross-origin resources |
| browser validation | Checks integrity during resource load | Blocks resource if hashes do not match |
Basic Example
This example shows how to use the integrity attribute with a <script> tag to load a library from a CDN. The hash is computed for the expected content of the script.
<script src="https://cdn.example.com/library.js" integrity="sha256-abc123def456..." crossorigin="anonymous"></script>The integrity attribute specifies the expected SHA-256 hash of the script. The crossorigin="anonymous" attribute is required for cross-origin requests to ensure the browser sends no credentials.
Production Example
This example shows a more robust implementation of SRI in a production context, including proper error handling and use of multiple hash algorithms for redundancy.
<script src="https://cdn.example.com/library.js" integrity="sha384-abc123def456... sha256-xyz789uvw012..." crossorigin="anonymous"></script>
<link rel="stylesheet" href="https://cdn.example.com/style.css" integrity="sha384-abc123def456..." crossorigin="anonymous">This version includes multiple integrity hashes to provide redundancy and uses SHA-384 for added security. The crossorigin="anonymous" attribute is also included to comply with CORS policies for cross-origin resources.
Common Mistakes
- Forgetting to include the
crossorigin="anonymous"attribute when loading cross-origin resources. This results in SRI being ignored by the browser. - Using outdated or incorrect hash algorithms, such as MD5 or SHA-1, which are considered insecure and unsupported in modern implementations.
- Generating hashes manually instead of using tools or build scripts, leading to human errors or outdated hashes.
- Not updating the integrity hash when a resource is updated, causing the browser to block the new version.
- Applying SRI to resources that are not cross-origin, which is redundant and may cause confusion or misconfiguration.
Security And Production Notes
- Always use SHA-256, SHA-384, or SHA-512 for integrity hashes. Older algorithms like MD5 are no longer secure.
- Ensure that the
crossorigin="anonymous"attribute is included for cross-origin resources to allow integrity checks. - Hashes should be generated from the exact content of the resource, including whitespace and line endings.
- Consider using multiple hash algorithms to provide fallbacks in case one algorithm is compromised.
- Keep integrity hashes updated when resources are modified; otherwise, the browser will block the updated resource.
Related Concepts
Subresource Integrity is closely related to several other web security concepts. Content Security Policy (CSP) is a broader policy that restricts resource loading, and SRI is often used alongside CSP for layered protection. CORS (Cross-Origin Resource Sharing) defines how cross-origin requests are handled, and SRI relies on CORS headers for cross-origin integrity checks. HTTPS ensures encrypted communication, which is required for SRI to work properly. Finally, the concept of integrity checks is foundational to many security protocols, including digital signatures and certificate validation.