One of these features is called Subresource Integrity (SRI) and it's the topic of this post. I'll give you a brief description of SRI, tell you how it works, then share my opinion on how SRI fits into the world of tag management.
What is Subresource Integrity?
I'll quote Mozilla's simple explanation to make it easy:
Subresource Integrity (SRI) is a security feature that enables browsers to verify that resources they fetch are delivered without unexpected manipulation.
It's that last part about "without unexpected manipulation" where this becomes a security concern.
What is the purpose of SRI?
For example, all of the shared libraries that Google hosts have versioned URLs where the files are expected to remain unchanged. For jQuery 3.4.1 the URL is:
A generated hash of that file is:
jquery.min.js have not changed. If that file were to be hacked, or manipulated unexpectedly, the hash generated by the browser would differ from the one you coded in your page and the browser would actually block the file all together.
Should you use SRI in your tag manager?
https://www.google-analytics.com/analytics.js , but this file is not versioned. Google updates the contents of that file constantly to fix bugs and add features. If you add SRI for this file, it might work for a week or two, but eventually, once Google updates it, the hash will change, causing SRI to block the file in the browser.
Unfortunately, this scenario applies to nearly all tag vendors that you load on your website. The security feature designed to protect you from maliciously altered files also prevents a frequently-changed file from loading, even when the changes are part of the software design.
Tealium allows you to use SRI with TiQ on the bundled utag.js file. While this won’t mitigate the risk of any additional tags (utag.n.js) or third party scripts being told to load by those tags, it does help to mitigate the risk of utag.js being maliciously altered.
Learn more about how to implement SRI with Tealium here.
What can you do besides SRI?
- Scripts Loading Scripts
- Scripts Modifying Global Namespace
- Use HTTPS
This almost goes without saying, but make sure that every third-party file you load on your site is available via HTTPS.
- Use Content Security Policy (CSP)
Use a CSP to help mitigate scripting attacks through your site. This requires some back-end changes to your web servers, but it's worth considering for the added security.