In two high-profile data breaches this year – at Ticketmaster and British Airways – over half a million credit cards were stolen via a compromised script inserted on the payment pages.

Update 8/7/19: British Airways was fined a record £183m over this data breach, under new GDPR regulation. They are contesting the fine.

Google Tag Manager is a powerful tool which enables you to insert any script you want onto pages of your website, but that power can used against you by hackers if you’re not careful – and below we’ll look at how to stop GTM being a security risk on your payment pages.

Firstly, how did the hackers get the card details from these sites? And how is it relevant to GTM on your site?

Security firm RiskIQ has traced the breach to a compromised Javascript file which skimmed the card details from the payment form. So when a user entered their credit card number and security code on BritishAirways.com (or their mobile app) those details were posted to a third party server, unknown to British Airways or the customer. This is a high-scale equivalent of placing a skimming devices on an ATM, which reads one card at a time.

In Ticketmaster’s hack the script was one loaded from a chatbot vendor on their site, Inbenta. Inbenta claims not even to have been aware the script was used on payment pages. The changes to the script were subtle: not breaking any functionality, and in BA’s case using a domain ‘baway.com’ which looked somewhat authentic.

To protect your site against a similar attack you obviously need to lock down accounts used by your developers to change scripts in the page source code, but you also need to secure GTM – which can be used to deploy such scripts.

We have a few rules at Littledata to help reduce risks in using tag management on payment pages:

1. Use pixels over custom JavaScript tags on payment pages

You probably need a few standard tags, such as Google Analytics, on payment pages but try to avoid any custom scripts which could possibly skim card details. Many non-standard tags use JavaScript only to create the URL of a tracking pixel – and it is much safer (and faster) to call the tracking pixel directly. Contact the vendor to find out how.

(Littledata’s Shopify app even removes the need to have any script on the payment pages, by hooking into the order as it’s registered on Shopify’s servers)

2. Avoid loading external JavaScript files in GTM

Many vendors want you to load a file from their server (e.g. myvendor.com/tracking.js) from GTM, so they can update the tracking code whenever they want. This is flexible for them, but risky for you. If the vendor gets hacked (e.g. with Inbenta above) then you get compromised. It’s less risky to embed that script directly in GTM, and control version changes from there (although a fraction slower to load the page).

Of particular risk is embedding a tag manager within a tag manager – where you are giving the third party rights to publish any other scripts within the one tag. Don’t do that!

3. Lock down Edit and Publish rights on GTM

Your organisation probably has a high turnover of contract web developers and agencies, so have you checked that only the current staff or agencies have permission to edit and publish? It’s OK to have external editors use ‘workspaces’ for version control in GTM, but ideally someone with direct accountability to your company should check and Publish.

4. Blacklist custom JavaScript tag on the payment pages

You can set a blacklist from the on-page data layer to prevent certain types of tags being deployed on the payment pages. If you have a GTM container with many users, this may be more practical that step 3.

5. Remove tags from old vendors

There are many thousands of marketing tools out there, and your company has probably tried a few. Do you remove all the tags from vendors when you stop working with them? These are most at risk of being hacked. At Littledata we run a quarterly process for marketing stakeholders opt-in tags they still need for tracking or optimisation.

6. Ensure all custom JavaScript tags are reviewed by a developer before publishing

It can be hard to review minimised JavaScript libraries, but worth it for payment pages if you can’t follow rules 1 and 2.

If you’re still worried, you can audit the actual network requests sent from payment pages. For example, in Chrome developer tools, in the ‘Network’ tab, you can inspect what requests sent out by the browser and to what servers. It’s easy for malicious code to hide in the patchwork of JavaScript that powers most modern web experiences, but what is harder to hide is the network requests made from the browser to external servers (i.e. to post the stolen card information out).

This request to Google Analytics is fine, but if the domain of a request is dubious, look it up or ask around the team.

Good luck, and keep safe with GTM!