Modern websites are built by referencing images, content, and scripts from various locations around the web. Subresource integrity (SRI) allows a browser to verify that the contents of a requested file have not been unexpectedly modified.
While their use cases compliment each other, SRI is different from a Content Security Policy (CSP), which ensures that only files from trusted sources are allowed on your website. SRI goes one step further by ensuring that the content of these files match your expectations.
For more detailed information about SRI, refer to the MDN web docs.
The SRI validation process can be summarized as follows:
integrityattribute of the HTML element that loads the file.
integrityattribute, the browser requests the resource and independently generates its own version of the cryptographic hash.
integrityhash with the one it generated. If they match, the asset is allowed. If they do not match, the asset is blocked.
<script> element (embed code). The dynamic functionality afforded by the TMS is accomplished by swapping out the contents of that script dynamically without requiring you to change anything else.
When the script contents change, however, so does the cryptographic hash of those contents. Therefore, 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 build. For many, this defeats the primary purpose of using a TMS in the first place.
The next best security option for Platform Launch is to implement a Content Security Policy. For more information, see the guide on CSPs in Platform Launch.
If you still wish to use SRI for your library builds, you must use self-hosting. If you are using Adobe-managed hosting, there is no way to use SRI without having some amount of time where the new build contents do not match the
integrity attribute of the embed code.
Automating the process of updating your embed code will vary in complexity depending on the structure of your site, but the general steps can be summarized as follows:
integrityattribute is updated to the new hash, and that the referenced build is updated as part of the same deployment.
This approach only covers the main build. It does not include any of the smaller files that may exist.
This document covered the limitations of using SRI in Platform Launch, and the steps required to integrate it into your library build deployments despite those limitations. If you have not already, it is strongly recommended that you read the guide on CSPs in Platform Launch for an alternative security option.