Category: Attack Techniques

Subresource Integrity

Also known as:

Simply put

Subresource Integrity is a browser security feature that lets websites verify that files loaded from external sources, such as Content Delivery Networks (CDNs), have not been tampered with. It works by allowing a website to specify a cryptographic hash for each external resource, so the browser can check that the downloaded file matches the expected content before executing it. This helps protect users from attacks where third-party hosted files are maliciously modified.

Formal definition

Subresource Integrity (SRI) is a W3C specification that defines a mechanism by which user agents verify that fetched resources have been delivered without unexpected manipulation. Web authors include a cryptographic hash (typically SHA-256, SHA-384, or SHA-512) in the 'integrity' attribute of HTML elements such as <script> and <link>. The browser computes the hash of the fetched resource and compares it against the declared value; if the hashes do not match, the resource is blocked from loading. SRI is applicable to both cross-origin and same-origin resources, though its primary security value is in mitigating risks associated with externally hosted assets, where the serving infrastructure (such as a CDN) may be compromised independently of the origin. SRI does not detect or prevent all supply chain attacks; for example, if an attacker compromises the build process before hashes are generated, the integrity attribute would reflect the tampered content. Additionally, SRI is not suitable for resources that change dynamically, since any modification to the resource content will invalidate the hash.

Why it matters

Modern web applications routinely load JavaScript libraries, CSS frameworks, and other assets from external sources such as Content Delivery Networks. This reliance on third-party infrastructure introduces a significant attack surface: if a CDN or external host is compromised, an attacker can inject malicious code into resources that are then served to every site depending on that CDN. Because browsers trust and execute scripts loaded via valid HTML tags, a single tampered file can affect millions of users across thousands of websites simultaneously. Subresource Integrity provides a critical defensive layer against this class of supply chain attack by ensuring that any modification to a fetched resource, whether through CDN compromise, man-in-the-middle attacks, or other forms of tampering, results in the browser blocking the resource rather than executing it.

The importance of SRI has grown alongside the expansion of the web supply chain. Organizations that rely on externally hosted assets without SRI have no browser-enforced mechanism to detect unauthorized changes to those resources between the time of authoring and the time of delivery. While SRI is not a comprehensive solution to all supply chain risks (for example, it cannot protect against compromises that occur before hashes are generated), it is one of the most accessible and widely supported browser-native controls available for verifying the integrity of fetched content. Implementing SRI is a recommended practice by OWASP and is part of a defense-in-depth strategy for web application security.

Who it's relevant to

Front-End Web Developers

Developers who include third-party scripts or stylesheets from CDNs are directly responsible for implementing SRI attributes. Adding integrity hashes to external resource tags is a straightforward step that provides meaningful protection against CDN compromise or delivery-time tampering.

Application Security Engineers

Security teams should verify that SRI is consistently applied across web properties, particularly for externally hosted resources. SRI enforcement can be included in security reviews, automated scanning policies, and Content Security Policy configurations to ensure broad coverage.

DevOps and Build Pipeline Engineers

Teams managing build and deployment pipelines can automate the generation and verification of SRI hashes as part of the build process. This ensures that integrity attributes stay current when dependency versions are updated and reduces the risk of human error in hash management.

Software Supply Chain Security Practitioners

SRI is one layer in a broader supply chain security strategy. Practitioners focused on the integrity of software delivery should understand both SRI's value in verifying fetched resource integrity and its limitations, particularly that it does not address compromises occurring before hash generation.

Compliance and Risk Management Teams

Organizations subject to security standards or regulatory frameworks that mandate integrity controls for web-delivered content should consider SRI as part of their compliance posture. It provides an auditable, browser-enforced mechanism for verifying that external resources have not been modified.

Inside SRI

Integrity Attribute

An HTML attribute added to <script> or <link> elements that contains a cryptographic hash value, allowing the browser to verify that a fetched resource has not been altered before execution.

Cryptographic Hash Algorithm

The hashing algorithm used to produce the digest, typically SHA-256, SHA-384, or SHA-512. The algorithm identifier is prefixed to the base64-encoded hash value in the integrity attribute (e.g., sha384-...).

Base64-Encoded Digest

The output of the chosen hash function, encoded in base64, representing the expected content of the resource. The browser computes a hash of the fetched resource and compares it against this value.

Crossorigin Attribute

An attribute that must typically accompany the integrity attribute for cross-origin resources, enabling CORS so that the browser can perform byte-level validation on the fetched content.

Failure Behavior

When a hash mismatch is detected, the browser blocks execution or application of the resource and may fire an error event, preventing potentially tampered content from running in the page context.

Multiple Hash Support

The integrity attribute may contain multiple hash values, potentially using different algorithms. The browser selects the strongest algorithm present and considers the resource valid if it matches any hash of that strongest algorithm.

Common questions

Answers to the questions practitioners most commonly ask about SRI.

Does SRI only work for third-party resources, not same-origin ones?

SRI can be applied to both third-party and same-origin resources. The integrity attribute is evaluated by the browser regardless of origin. However, SRI provides less additional security value for same-origin resources because if the origin server itself is compromised, the attacker could typically modify both the resource and the integrity hash in the HTML document simultaneously. For third-party resources, SRI is particularly valuable because the HTML document and the external resource are under separate administrative control.

Does implementing SRI eliminate the need for Content Security Policy (CSP)?

No. SRI and CSP address different threat surfaces and are complementary rather than interchangeable. SRI verifies that a specific fetched resource has not been tampered with by comparing its content against a known cryptographic hash. CSP controls which sources the browser is permitted to load resources from in the first place. SRI does not restrict resource origins and CSP does not verify resource content integrity. Using both together provides defense in depth: CSP limits where resources can originate, while SRI ensures that permitted resources have not been modified.

Which HTML elements support the integrity attribute for SRI?

Browser support for SRI is defined for <script> and <link> elements (the latter typically used for stylesheets). These are the element types specified in the W3C Subresource Integrity specification. Other resource types, such as images or fonts loaded via HTML attributes, do not currently support the integrity attribute. For resources loaded via JavaScript, the Fetch API supports an integrity option that enables SRI checks programmatically.

What happens when an SRI hash does not match the fetched resource?

The browser blocks the resource from loading or executing entirely and typically reports a network error for that request. This is a fail-closed behavior: the page may lose functionality that depended on the blocked resource, but it will not execute tampered content. This means that hash mismatches caused by legitimate resource updates, such as when a CDN-hosted library is updated without a corresponding hash update in your HTML, will also result in the resource being blocked. Monitoring for SRI failures in production is important to distinguish attacks from maintenance issues.

How should SRI hashes be managed when external resources are updated frequently?

For frequently updated resources, SRI hashes must be regenerated and deployed in the HTML each time the resource content changes. This is typically handled through build-time automation: tooling computes the hash of each resource and injects the correct integrity attribute into the HTML during the build or deployment pipeline. Pinning to specific versioned URLs of external resources, rather than using URLs that point to a latest or mutable version, reduces the frequency of hash changes and makes SRI more practical to maintain.

Does the crossorigin attribute need to be set when using SRI with resources from a different origin?

Yes. For cross-origin resources, the crossorigin attribute must be set on the element (typically to 'anonymous') and the remote server must return appropriate CORS headers. Without CORS, the browser may not perform the integrity check correctly, or may block the resource regardless of whether the hash matches. For same-origin resources, the crossorigin attribute is not required for SRI to function, though it may still be present for other reasons.

Common misconceptions

SRI protects against all forms of resource tampering, including modifications made at the origin server itself.

SRI verifies that a fetched resource matches a pre-computed hash. It works for both same-origin and cross-origin resources, but it offers little additional protection when the origin server itself is compromised, because an attacker who controls the origin could also influence the expected hash values or serve arbitrary content that the page author unwittingly hashes.

SRI can be applied to any type of external resource loaded by a web page, such as images, fonts, and iframes.

Browser support for SRI is currently limited to <script> and <link> elements in most implementations. Other resource types, such as images, media, or iframes, are typically not covered by SRI enforcement.

SRI eliminates the need for other supply chain protections like Content Security Policy when loading third-party scripts.

SRI and CSP address complementary concerns. SRI validates resource integrity against a known hash, while CSP restricts which origins or sources may load resources at all. Using both together provides layered defense, and neither alone covers the full scope of third-party resource risks.

Best practices

Generate SRI hashes using SHA-384 or SHA-512 for all third-party scripts and stylesheets, and include the integrity attribute on every corresponding <script> and <link> element.

Always pair the integrity attribute with a crossorigin attribute (typically crossorigin="anonymous") for cross-origin resources to ensure the browser can perform CORS-based byte-level validation.

Automate SRI hash generation and updates as part of the build or deployment pipeline to prevent hash mismatches when third-party resources are intentionally updated.

Combine SRI with a Content Security Policy that includes the require-sri-for directive (where supported) or equivalent CSP restrictions to enforce integrity checks as a policy rather than relying solely on per-element attributes.

Pin specific versions of third-party resources rather than referencing 'latest' URLs, since SRI hashes are tied to exact file contents and any upstream change will cause a loading failure.

Monitor for SRI-related error events in the browser (e.g., via reporting endpoints or error logging) to detect unexpected hash mismatches, which may indicate resource tampering or uncoordinated upstream updates.