Secure Configuration of Google Tag Manager

tags: analytics, google tag manager, security
created: Tue 31 October 2017; status: published;

If you have to host a Google Tag Manager Container owned or managed by someone else, you need to take precautions. Tag Manager has powerful analytics orchestration capabilities and is a great way to move their complexity from engineering to another group like marketing or strategy. It also has real dangers, including the ability to inject untrusted Javascript straight into the page.

The instant you embed a Tag Manager Container you do not control, you potentially open your page to multiple types of hijacking and data-scraping attacks. Really, this is true of your own Container as well, and you should lock that down. You feel secure about your own container because you've enabled 2-factor authentication. Did that client, though? Will they turn it off in the future? Or will an admin account be compromised who can then turn off the flag?

The danger is of an outsider using the "Custom HTML" Tag to insert malicious Javascript. You need to be worried about this. You can also prevent it.

Enable "2-Factor Verification for certain operations"

Do this for your all of your own accounts, and insist your client do it as well. See the screenshot below.

When enabled, a user trying to create a dangerous Tag like "Custom HTML" will be forced to re-validate themself via a second method, such as a text message. This may prevent an attacker from making this change. However, it may not, as a sophisticated hacker may also have compromised the entire Google Account and have other means to accomplish or disable the 2-factor prompts.

[caption id="attachment_3422" align="aligncenter" width="300"] Screenshot of 2-factor authentication option[/caption]

Lock down capabilities with blacklist and whitelist

Use the 'dataLayer' to blacklist dangerous Tags. Even better, use a whitelist to add an extra wrapper of protection.

<script>
  // safely retrieve or create the dataLayer
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    'gtm.blacklist': ['customScripts']  # blacklist every item that can insert user-written Javascript
  });
</script>

This must appear before the Tag Manager <head> snippet. The full list of options for restricting Tags includes quite a few more. The options are pretty overwhelming - dozens of individual Tags, Triggers, and Variable types, plus groupings of them.

To simplify the security decisions, you can whitelist instead of blacklist. Blacklist prevents using specific Tags, Trigger, or Events. Whitelist does the opposite, it allows specific items.

Your client may only want Google Analytics orchestration via the Tag Manager. The dozens of other options may be of no interest to them. In that case, you should use a whitelist to lock the behavior down to the smallest, safest set of options possible.

Use this to allow only Google-hosted scripts and items: Analytics. Optimize, Adwords, DoubleClick, Surveys, etc.

<script>
  // safely retrieve or create the dataLayer
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    'gtm.whitelist': ['google']  # only allow Google-controlled items
  });
</script>

I highly suggest keeping a blacklist and whitelist. In the future, if someone changes the whitelist to enable previously-blocked capability A, they may inadvertently allow too much, suddenly allowing a Custom HTML Tag or other item that had so far been prevented from firing.

Thus, the safest approach is to whitelist the minimum and blacklist the most dangerous items:

<script>
 // safely retrieve or create the dataLayer
 window.dataLayer = window.dataLayer || [];
 window.dataLayer.push({
   'gtm.whitelist': ['google'],
   'gtm.blacklist': ['html']
 });
</script>

Summary

Insist your client enable the "Require 2-step login verification for certain operations" setting in their Tag Manager Account
Use Tag Manager's whitelist and blacklist to prevent running dangerous code, either by a client or by a hacker accessing a compromised account