What is Subresource Integrity (SRI)?

A web developer wishing to use a CDN to improve speed and performance needs to make sure that the CDN only serves content that he or she expects. But third-party-hosted resources such as scripts and stylesheets are vulnerable to manipulation. An attacker with access to the CDN can manipulate or replace a file - or trick the user into downloading content from a compromised server. Technologies such as SSL/TLS and HSTS ensure that the target resource is securely downloaded from the third party. But these technologies do not verify whether the downloaded resource has been compromised. TLS and HSTS cannot prevent attacks at the host level; they can only prevent attacks during transit. Enter SRI: Web developers use SRI to instruct the browser to only run unaltered scripts that match what’s in the website’s HTML.

SRI lets developers specify a base64-encoded cryptographic hash of the resource they expect to load upon request. The integrity attribute containing the hash is then added to the HTML elements such as <link> and <script> tags. This integrity string consists of a base64-encoded hash, followed by a prefix that depends on the hash algorithm. This prefix can either be sha265, sha384 or sha512. For example - sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC - is an integrity string based on base64-encoded sha384 hash. When the browser encounters an HTML element such as a <link> or <script> with an integrity attribute, it will first compare the element to the expected hash as specified by the integrity value on the third party host. If there is a match, the browser loads the resource. But if the element value in the HTML does not match the integrity value of the third party resource, the browser refuses to load the resource. Instead it returns an error that says the fetched resource could not be loaded.

CORS needs to be enabled for SRI to work: crossorigin="anonymous"

Suppose that 0mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS is the expected sha384 hash of script /bootstrap/3.3.6/js/bootstrap.min.js and that a copy of the script lives on a CDN at https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js. The corresponding script is:

<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js" integrity="sha384-0mSbJDEHialfmuBBQP6A4Qrprq5OVfW37PRR3j5ELqxss1yVqOtnepnHVP9aJ7xS" crossorigin="anonymous"></script>

When a request for the script is received, the browser verifies that the hosted script matches the expected hash. Because everything checks out, https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js is executed.

Only browsers that support SRI will refuse to execute third party resources with invalid hash. Browsers with no SRI support will still load the manipulated asset.

To learn how to implement SRI in your build process, check out this Mozilla Hacks article by Justin Dorfman.

Subresource Integrity makes websites safer, especially when developers want a page’s resources to be fetched from a third party host where they don’t have full control.

• More user trust in websites as users’ browsers will refrain from loading compromised resources.
• More developer trust in third party hosts as third parties now have a counter measure for resource manipulation.
• Keeps developers informed of security issues by alerting them of compromised resources.

SRI is a low-risk technology with several security gains to website owners, developers, visitors, CDN providers, and other third party hosts. It helps all types of websites mitigate the risk of attacks that may arise from compromised third party resources. SRI does this by verifying that the resource delivered by the third party is an exact representation of the original.

As always, If you have any questions or concerns about any of the topics mentioned in this article, please feel free to reach out to support. Live chat and ticket support are available 24/7.