When building websites, significant performance gains can be made by using files from a Content Delivery Network (CDN). CDNs usually have nodes much more local (physically) to a visitor, and common files used across many sites (such as jQuery, bootstrap, etc.) may even be already in the visitor’s cache.
However, if you’re using a file from a CDN, well, you don’t really control it. Someone could change it, for honest or nefarious reasons – and your site would still load that resource and try to use it.
To be honest, I take it as a sign of how well run many of these CDNs are run; I can only imagine that changing JavaScript files on one would be a nice, inviting target. You change would then start to affect all the websites that use that file – potentially thousands of individual sites. I sort of expected that we’d have seen more incidents like this already (though they have happened. Kudos for the very honest post-mortem too).
Now, the big CDNs are all pretty responsible, but bad things happen – so how can we guarantee that the resource we want the visitor’s browser to load hasn’t been modified?
That’s what Subresource Integrity (SRI) gives us. There’s plenty of details about this at these locations:
- https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/
- https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
- https://www.troyhunt.com/protecting-your-embedded-content-with-subresource-integrity-sri/
…but the short form is that links to the file include a file hash. The browser checks the file it receives against the hash – and disregards it if they don’t match.
However, just disregarding this file leaves us with a problem – if your site relies on jQuery or similar, well, you’ve got a broken site. It really needs fallback.
There are some examples in the above articles that show using JavaScript to load an alternate file if the one you were trying to load didn’t work, but I have a few problems with this:
- I’m trying to eliminate inline JavaScript. I want my Content Security Policy (CSP) to block inline script. That’s a reasonable objective.
- It feels like a hack. I mean, the browser know’s it’s rejected the file it received. Is it that hard to have it load from an alternate URL, if provided?
- It’s a pain. As a developer, having to code a fallback each time is a harder than just specifying an alternate URL attribute.
I’m not the first to suggest this, and I doubt I’ll be the last.
Another enhancement to SRI that’s been proposed is that CSPs can also specify that they require-sri-for resources. That’s pretty neat; I can totally see someone forgetting to add SRI to a tag that points to a CDN, and this would make a good way of detecting and fixing those.
However, it seems to me that implementing that should be a lot harder than offering a fallback URL.
Maybe they’ll add it in the future. In the meantime, I guess we have to hack to make it work, or live without fallback.
Andy Burns' Blog 