Sponsored by:

SRI

A 2-post collection

The JavaScript Supply Chain Paradox: SRI, CSP and Trust in Third Party Libraries

A couple of years back as the US presidential campaign was ramping up, the Trump camp did something stupid. I know, we're all shocked but bear with me because it's an important part of the narrative of this post. One of their developers embedded this code in the campaign's donation website: <script src="https://github.com/igorescobar/jQuery-Mask-Plugin/blob/gh-pages/js/jquery.mask.min.js" type="text/javascript></script> See the problem? This tag was in the source code over at secure.donaldjtrump.com/donate-homepage yet it was pulling script directly off Igor Escobar's GitHub repository for the project. Now, imagine if Igor took a dislike to Trump. Or someone else took issue with the bloke...

Protecting your embedded content with subresource integrity (SRI)

CDNs are good. You get to put your web things all over the world and then have them served to your global audience from a location close to them. For example, because this blog is served through CloudFlare and about two thirds of the requests to my site come direct from their cache, you're probably downloading all the images on this page from whichever point in the map below is closest to you: But what's even better than CDNs when it comes to cost and performance is public CDNs. For example, on Have I been pwned (HIBP) I serve various CSS and JavaScript files that are public libraries. It's stuff like jQuery and Bootstrap and my files are in no...