Overview
SRI, or Subresource Integrity, is a security feature that allows web developers to ensure that resources loaded from third-party origins—such as scripts, stylesheets, or fonts—have not been tampered with. It does this by using cryptographic hashes to verify the integrity of the resource at runtime.
When a resource is fetched, the browser checks its hash against the one specified in the HTML tag. If the hashes do not match, the browser blocks the resource and prevents its execution. This mechanism is particularly useful in environments where external resources are used but cannot be fully trusted, such as CDNs or public libraries.
Why It Matters
Without SRI, a malicious actor who compromises a CDN or a third-party service can inject harmful code into resources that are loaded by your application. SRI prevents such attacks by ensuring that only the exact resource you expect is executed.
For developers maintaining large applications, SRI acts as a safeguard against supply chain attacks. It is especially critical in high-security environments such as financial, healthcare, or government platforms, where integrity of external code is non-negotiable. It also helps in compliance with security standards like NIST SP 800-53 or OWASP Top 10.
How It Works
The SRI mechanism relies on cryptographic hash functions to validate resources. When a resource is included in HTML, a hash is calculated for the expected content and embedded in the tag using the integrity attribute.
- The integrity attribute is supported on
<script>,<link>, and<iframe>elements. - Hash algorithms must be SHA-256, SHA-384, or SHA-512, and must be prefixed with the algorithm name.
- The hash value is base64-encoded and must match the resource exactly.
- When a browser fetches a resource, it calculates the hash of the downloaded content and compares it with the integrity hash.
- If the hashes do not match, the browser blocks the resource and logs an error to the console.
Quick Reference
| Item | Purpose | Notes |
|---|---|---|
| integrity attribute | Specifies the hash of the resource | Required for SRI to function |
| hash algorithm | SHA-256, SHA-384, or SHA-512 | Must be prefixed in the integrity value |
| base64 encoding | Format of the hash value | Browser expects base64-encoded value |
| Resource matching | Browser compares downloaded content | Failure blocks resource loading |
| HTML tag support | script, link, iframe | Not supported on all elements |
Basic Example
This example demonstrates how to include a JavaScript library with SRI enabled using the <script> tag.
<script src="https://cdn.example.com/library.js" integrity="sha384-abc123def456ghi789jkl012mno345pqr678stu901vwx234yz567" crossorigin="anonymous"></script>The integrity attribute contains a base64-encoded SHA-384 hash of the expected file content. The crossorigin attribute is used to signal that the resource should be fetched with CORS headers.
Production Example
In production, developers often use build tools to generate integrity hashes automatically. This ensures that the hashes are always up to date and that manual errors are minimized.
<link rel="stylesheet" href="https://cdn.example.com/style.css" integrity="sha256-xyz789uvw012rstu345vwx678abc901def234ghi567" crossorigin="anonymous">This example shows a CSS file loaded with SRI. It is more suitable for production because it is part of a larger security strategy that includes automated hash generation and consistent deployment practices.
Common Mistakes
- Using an outdated or incorrect hash algorithm, such as MD5 or SHA-1, which are not supported by browsers.
- Forgetting to include the
crossoriginattribute when loading resources from a different origin, which can cause SRI to fail. - Manually updating the integrity hash without re-fetching the resource, leading to mismatched hashes.
- Applying SRI to resources that are frequently updated, which can cause the system to break without frequent hash updates.
- Not testing SRI in different environments, leading to runtime failures in staging or production due to mismatched hashes.
Security And Production Notes
- SRI is not a replacement for HTTPS; it must be used in conjunction with secure connections.
- Hashes must be generated using the exact content of the resource, including whitespace and comments.
- When using build tools, ensure that integrity hashes are updated automatically to avoid stale values.
- Consider using Content Security Policy (CSP) alongside SRI for additional protection.
- Failure to properly implement SRI can lead to broken resources in production, especially in environments with strict caching or CDN configurations.
Related Concepts
SRI is closely related to several security mechanisms in web development:
- Content Security Policy (CSP): A security layer that helps detect and mitigate certain types of attacks, including XSS and data injection.
- Cross-Origin Resource Sharing (CORS): A mechanism that allows restricted resources on a web page to be requested from another domain.
- Subresource Loading: The process of loading resources like scripts and stylesheets, which SRI secures.
- Hash Functions: Cryptographic functions used to generate integrity values, such as SHA-256, SHA-384, and SHA-512.
- Supply Chain Security: A broader security domain that includes protecting code from tampering during distribution and delivery.