the basics for using subresource integrity

Recently, I leveraged a CDN to load a stylesheet. This was great because it meant that my users didn’t have to wait as long to get the resources they needed for the site to function.

Unfortunately, whenever you’re using a resource you don’t control, there’s an opportunity for malicious actors.

Though TLS can make sure there’s no man-in-the-middle, it doesn’t mean that the resources you’re retrieving haven’t been compromised.

One tool in the box to prevent this is the Subresource Integrity (SRI). SRI solves this problem by creating a hash of the resource. If it changes, it isn’t downloaded.¹

Using SRI is made very simple with https://www.srihash.org/ which also includes a few useful notes, like this one about why crossorigin: "anonymous" is necessary:

When the request is not on the same origin the crossorigin attribute must be present to check the integrity of the file.

Without a crossorigin attribute, the browser will choose to ‘fail-open’ which means it will load the resource as if the integrity attribute was not set, effectively losing all the security SRI brings in the first place.

crossorigin="anonymous" results that no credentials are sent to the cross-origin site hosting the content. However, it will send an Origin HTTP header. If the server denies including the resource (by not setting the Access-Control-Allow-Origin HTTP header), the resource will not be used by the browser.

You can find more information on MDN.

Footnotes

• ¹ In this event, depending on the resource, you may want to consider your fallback plan. Jakub Mikuláš wrote a great piece about how to define a fallback in this post on sri.js.org.