the basics for using subresource integrity



~2 min read


277 words

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.1

Using SRI is made very simple with 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.


  • 1 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

Related Posts
  • 2022-daily-journal
  • Remix: Getting Syntax Highlighting Working

  • Hi there and thanks for reading! My name's Stephen. I live in Chicago with my wife, Kate, and dog, Finn. Want more? See about and get in touch!