Sub-resource Integrity(SRI) and Launch

[#1]

Modern websites are built by referencing images, content, and scripts from various locations around the web. Sub-resource integrity (SRI) allows a browser to verify that the contents of the requested file have not been unexpectedly modified.

SRI is different from a Content Security Policy (CSP), though they work together. When implemented correctly, a CSP ensures that only files from trusted sources are allowed on your site. SRI goes one step further by ensuring that the contents of these files match your expectations. You can read all about SRI and see examples on the MDN web docs. The basics:

1. You generate a cryptographic hash of the asset that you want to validate
2. You put that hash in your site's HTML as the integrity attribute of the HTML element that loads it
3. When the browser sees the integrity attribute, it will request the resource and independently generate the cryptographic hash
4. The browser compares the integrity hash with the one it generated - if they match, the asset is allowed; if they do not match, the asset is blocked

Those who are familiar with how tag management systems work may now be catching on to a fundamental incompatibility between SRI and a TMS. 

Tldr; Tag management systems give you a compiled JavaScript library that you load onto your pages with a single <script> element. The dynamic functionality you get from your TMS is accomplished by swapping out the contents of that script dynamically - without requiring you to change anything else. But when the script contents change, so does the cryptographic hash of those contents. Thus, the only way to make SRI work with a TMS is to update your embed code at the same time that you publish a new library. For many people, this defeats the primary purpose of using a TMS in the first place.

So is it possible?

If you self-host your Launch library, it can be done, but it is not for the faint of heart. In broad strokes:

1. Get the production library (either through SFTP delivery or downloading the archive from the UI)
2. Generate the cryptographic hash of the main library
3. Coordinate a deploy of your site that includes updating the integrity attribute of your embed code and the new library

Note that this approach covers only the main Launch library, it does not include any of the smaller files that probably exist (though this depends on your setup).

If you are using Launch's built-in hosting option, there is no way to use SRI without having some amount of time where the new library contents do not match the integrity attribute in the embed code.

What's the next best option?

From a security standpoint, the next best option in Launch is to implement a CSP. Launch does support usage of a CSP using the nonce method of validating sources. You can read more about that here.