Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

Sub-resource Integrity(SRI) and Launch

Avatar

Avatar
Contributor
Employee
thebenrobb
Employee

Likes

139 likes

Total Posts

310 posts

Correct Reply

82 solutions
Top badges earned
Contributor
Seeker
Shape 1
Give Back 3
Give Back
View profile

Avatar
Contributor
Employee
thebenrobb
Employee

Likes

139 likes

Total Posts

310 posts

Correct Reply

82 solutions
Top badges earned
Contributor
Seeker
Shape 1
Give Back 3
Give Back
View profile
thebenrobb
Employee

18-08-2020

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.