Tag managers and client-side risk: why they widen the attack surface, and how to govern them

What a tag manager is, and why teams use it

A tag manager is a service that your pages load as a single script. From a web console, marketing, analytics and product teams then configure which "tags" (small pieces of code or vendor scripts, such as analytics, advertising pixels and survey tools) run on which pages and when. Changes go live when someone publishes a new version of the container; no developer or release process is involved.

That speed is why tag managers are popular, and it is also what changes the security picture. The people who can publish are often outside the engineering team and its review process, and the container is a script that can contain, or load, any other script.

Why tag managers widen the attack surface

• Publish rights equal code execution. A tag manager account with publish permission can add custom code that runs on every page. An attacker who steals or phishes one such account does not need to touch your site or servers.
• Changes bypass change control. A tag added in the console is not in your repository, your code review or your deployment log, unless you make the console part of your change process.
• Chains of scripts. A tag loads a vendor script, which may load other scripts. The container's list of tags is therefore a poor guide to what really runs.
• The container is itself a third-party script. It can change at any time, so it cannot be pinned with Subresource Integrity, and its content depends on who published last.
• Pressure on your Content Security Policy. Some tag manager features rely on inline code or on building code from strings, which weaken a Content Security Policy unless handled carefully. Check your vendor's documentation for the policy it requires.
• Stale tags. Tags for campaigns that ended, tools no longer used or vendors no longer under contract linger and keep running.

These are risks of any third-party JavaScript, concentrated in one place and made easy to change.

How to govern a tag manager

Decide what belongs on payment pages

The simplest and strongest step is to keep the tag manager, or at least its marketing tags, off the payment page. If the business needs something on that page, use a separate, restricted container with a short, reviewed list of tags, rather than the container that serves the whole site.

Control who can publish

• Give publish rights to as few people as possible, with multi-factor authentication on every account.
• Separate the right to edit from the right to publish, and require a second person to approve a publish.
• Remove accounts when people leave or change roles, and review the list on a schedule.
• Where the product allows it, disable or restrict custom code tags on payment pages.

Keep a record and compare it with reality

• List every tag with a business reason, an owner and an approval, as in how to build a payment page script inventory.
• Keep the container's version history and audit log, and review what changed in each publish.
• After each publish, check what the payment page really loads, including scripts the tags load in turn. Compare it with the approved list and alert on differences: how to detect client-side tampering.
• Remove tags that are no longer needed.

Treat the vendor as a third party

Understand how your tag manager vendor secures its service and its delivery, and manage the relationship under PCI DSS requirement 12.8. Server-side tagging, where a server rather than the browser sends data to vendors, reduces how much third-party code runs in the visitor's browser, but it moves the trust to your own server setup and does not remove the need for these controls.

Tag managers and PCI DSS

Requirement 6.4.3 applies to all scripts that are loaded and executed in the consumer's browser on a payment page. A script loaded by a tag manager is such a script, so it needs an entry in the inventory, an authorization and an integrity method like any other; and a change published in the console is a change that 11.6.1 should notice. See PCI DSS 6.4.3 explained.