All Collections
Silktide Analytics
Analytics FAQ
Does Silktide Analytics support subresource integrity (SRI) checks?
Does Silktide Analytics support subresource integrity (SRI) checks?
Julia Voortman avatar
Written by Julia Voortman
Updated over a week ago

What is subresource integrity?

A relatively modern web convention – Subresource Integrity – allows your HTML to guarantee that any 3rd party JavaScript it uses is what it expects.

This is a security measure which prevents damage if that 3rd party script is hacked.

For example, imagine if Google Analytics was hacked, and their JavaScript was changed. Every website using GA would suddenly be running unexpected code, that (for example) could be mining cryptocurrency or similar.

Subresource integrity is where you take normal HTML which loads JavaScript, like this:

<script src="<>"></script>

And you expand it by adding an integrity attribute, which is a cryptographic hash used to validate that the JavaScript it loads is what is expected:

<script src="<>" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" crossorigin="anonymous"></script>

The integrity code needs to be updated whenever the JavaScript is updated. It is this requirement which makes it difficult to support.

Why is it not generally supported by analytics providers?

At the time of writing, we are not aware of any major analytics provider which supports SRI as standard, including:

  • Google Analytics

  • Adobe Analytics

  • Silktide Analytics

  • Siteimprove Analytics

The main reason is because the underlying script itself is often changed, and when it is changed, the HTML that points to it will need updating or it will stop working.

Analytics code is usually updated quite regularly to incorporate new features, fix bugs, and address new browser capabilities or incompatibilities.

What can you do with Silktide Analytics?

If SRI is important to you, we propose the following workaround:

  1. Configure analytics exactly as you want it first. Silktide saves your analytics config inside your analytics JavaScript file, so you want to fix these settings before you start to use it. In most cases, the only setting you will care about will be the list of “Permitted URLs” which appears under Settings > General.

  2. Download your Silktide Analytics script file. As your JavaScript file will be specific to your web property, and contains config for your web property, there is no one ‘standard’ Silktide JavaScript file that you can copy. You can get the URL of your JavaScript inside Silktide by viewing your analytics property, go to Settings > Installation, and look for the src attribute of the sample code.

  3. Upload the downloaded JavaScript onto your own servers or CDN.

  4. Use this SRI Hash generator or this guide to generate your integrity hash.

  5. Add the JavaScript snippet from earlier (see above) to your website, but:

  6. Update the src to point to your new URL where you host the script.

  7. Add the new integrity attribute you generated.

  8. Add crossorigin="anonymous".

What about updates?

At this time there is no automated mechanism for receiving updates or notifications of updates to our analytics script.

This is because (a) it updates every time you change your analytics config and (b) we deploy updates to customer scripts in a distributed manner (i.e. patches to our script are gradually deployed over several days).


  1. All scripts are designed to be backward compatible, if this ever changes we will notify all customers by email

  2. Updates are generally relatively infrequent (quarterly)

In general you can safely host the fixed version of the analytics script and only aim to update it if you need to make an update to your analytics config (e.g. changing the URLs of your website). If major new functionality or backward incompatible changes are released, we will notify you.

Future plans

We are considering adding native support for SRI. This is not guaranteed, but we appreciate the desire for it. No-one else we know has done this, it is quite involved, and there are some usability tradeoffs.

  • We would introduce versioned JavaScript for you to host (i.e. each version of your analytics would be hosted forever, new releases would have a new URL)

  • Analytics would add an option to enable SRI. Enabling this would:

    • Change their HTML snippet to include automated SRI attributes and point to a static file that lacks dynamic config; the dynamic config would be moved into the snippet

    • Notify the user to update their HTML snippet if they change any config options which require it

    • Ask for any email addresses to be notified when updated analytics is available; we would automatically email them when minor and major updates occur.

Did this answer your question?