What is Subresource Integrity, and Does it Make Sense for TMS?

[ty_gavin]

These days there's no shortage of privacy and security issues to concern yourself with, and there's good reason for it. While the vast majority of online systems are secure, there's always a risk that one component in a system will get compromised. The way websites are built these days, with hundreds of components, many third-party JavaScript libraries have become ubiquitous and used by millions of sites. This is a great convenience to developers of websites, but it's also an attractive target for the "bad guys" that want to hack your site. Fortunately, the browsers we use everyday have built-in features to help protect us against hacked components like this.

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?

First off, "subresource" refers to the extra files that a web page fetches while the page is rendered in the browser. This includes all types of content, such as CSS files, font files, external JavaScript files, and many more. The "integrity" part just means that the page is receiving the exact file that it expects to get.

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.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

It's that last part about "without unexpected manipulation" where this becomes a security concern.

What is the purpose of SRI?

The goal of SRI is to protect your website from a compromised (i.e. unexpectedly manipulated) third-party JavaScript file. The idea is to create a hash of the known valid version of that file that the browser can use to verify that the file is unchanged each time it loads. This makes perfect sense for static files such as a specific version of jQuery.

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:  https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js

A generated hash of that file is:

sha384-vk5WoKIaW/vJyUAd9n/wmopsmNhiy+L2Z+SBxGYnUkunIxVxAv/UtMOhba/xskxh

By including this hash in your page code that loads that JavaScript, you allow the browser to validate that the contents of 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?

I know what you're thinking: browsers have a built-in security feature to validate third-party JavaScript files and you use Tealium iQ Tag Management to manage many of those third-party JavaScript tags on your site, so isn't SRI the perfect way to add an extra layer of security to your site?

Well, let's take a closer look at this. One of the big differences between JavaScript that's used for development and the script tags that are used for web analytics and marketing is the way they are versioned. For example, many websites all load the same Google Analytics tag from  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?

If you really need an additional level of security for your tag vendors then I recommend the following alternatives to SRI. These are ways to vet the security of the third-party JavaScript you load on your site.

• Scripts Loading Scripts
  Does the third-party JavaScript script load and then go on to load additional third-party JavaScript files? This is sometimes called "piggybacking" and it's not that uncommon. Be sure to understand what your tag vendor's code is actually doing.
• Scripts Modifying Global Namespace
  A common rule of JavaScript etiquette is to leave the global namespace as tidy as possible. Most vendors play friendly by creating a specific namespace for their tag and put all of their JavaScript logic there. Be sure to test your tag vendor's code to make sure there aren't unintended modifications to the 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.