Google Tag Manager Security: Permissions, publishing controls and defences against tag injection

Anyone who can publish a Google Tag Manager container can run JavaScript on every page that loads it, including login and checkout pages, without touching your code repository or your change process. That makes a GTM account one of the most powerful and least governed identities on a website: it is often owned by a marketing agency, protected by a personal Google Account, and published to production without review. This guide covers GTM's account and container permissions, how to contain Administrator and Publish rights, the Tag Manager API and service accounts, what to monitor, and the page side controls (allowlists, blocklists and template policies) that limit what a compromised container can do. It is for web security, application security and marketing operations engineers. The wider discipline of controlling third-party scripts, including PCI DSS payment page requirements, is in the Third-Party JavaScript Management Guide; this page goes deep on GTM itself. Facts were checked against Google's documentation on 8 November 2026.

This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.

Key takeaways

• Publish is production deployment. A user with Publish permission can push arbitrary script to the live site; manage it with the same discipline as deployment rights in your CI/CD pipeline.
• Account Administrators can grant themselves anything. In GTM 360 user groups, account Admins inherit Read on every container and can assign themselves more, so the Admin list is the real control boundary.
• Turn on the 2-step verification requirement. GTM can refuse changes to Custom HTML tags, Custom JavaScript variables and user settings unless the user's Google Account has 2-step verification, but the setting is off until an Administrator enables it.
• Constrain the container from the page. gtm.allowlist, gtm.blocklist and custom template policies run in your own page code, outside the container, so they still apply when a GTM account is compromised.
• Versions give you rollback and evidence. Every publish creates a version with the publisher recorded, so you can identify a malicious change and republish a known good version in minutes.

How identity and access work in Google Tag Manager

GTM grants access only to Google Accounts: Google Workspace accounts, Gmail accounts, or accounts created at accounts.google.com. There is no separate GTM login, so single sign-on and multi-factor authentication come from the Google identity that owns the account. A managed Workspace or Cloud Identity account inherits your SSO and 2-Step Verification policy; a consumer account inherits whatever its owner set. GTM adds one control of its own, the account level setting Require 2-step login verification for certain operations, described below.

Permissions sit on two levels. Account permissions decide who can create containers and manage users. Container permissions decide what a user can do inside each container, and they are assigned per container.

In GTM 360, user groups are available through Google Marketing Platform and members inherit the group's permissions. Google notes that direct permissions remain even when an inherited group or organisation permission is removed, so removing someone from a group does not guarantee removal from GTM. Check direct grants on every container.

Admin roles and privileged access

Google's own guidance is to keep at least two active Administrators, because a single Administrator who leaves can lock you out, and to make sure the account is managed by someone in your organisation rather than an external agency or consultant. GTM's Tag Diagnostics raises a notification when an account has only one Administrator. Build on that:

• Own the account: the GTM account belongs to your organisation and its Administrators are your staff on managed accounts. Agencies receive container level Edit, or Publish only where a contract and change process cover it.
• Separate edit from publish: give most users Edit, give reviewers Approve, and keep Publish to a small group. In GTM 360, approval requests let Edit users submit changes and Approve or Publish users accept, return or withdraw them.
• Enable the 2-step requirement: Admin, Account Settings, then Require 2-step login verification for certain operations. Once on, GTM checks that the user's Google Account has 2-step verification before allowing changes to Custom JavaScript variables, Custom HTML tags and user settings. This closes the most dangerous paths for an attacker holding only a stolen password, and it protects consumer accounts you cannot otherwise govern.
• Prefer phishing-resistant sign-in: for Administrators and publishers, require passkeys or security keys through Workspace policy, or enrol them in Advanced Protection: see the Google Advanced Protection Program Guide.
• Offboard through identity: suspending a managed account removes GTM access immediately; a consumer account must be removed from every container by hand.

Integrations, API tokens and service accounts

Tag Manager API

The Tag Manager API v2 uses separate OAuth scopes for each kind of power, which makes least privilege straightforward:

Google's authorisation page describes service accounts for automated access, such as a monitoring tool, using a P12 or JSON key downloaded from the API Console, and warns that the downloaded key is the only copy. A service account with tagmanager.publish and Publish permission is equivalent to a production deployer: keep its key in a secrets manager, rotate it, restrict who can impersonate it, and prefer keyless authentication where your runtime supports it. See the Google Cloud Service Account Keys Security Guide. A read only monitoring account is a good first automation: it lets you diff every published version against an approved baseline.

Environments and preview links

Environments let you publish any version to development or staging before Live. Each environment has its own snippet and authorisation code, and preview links can be shared. Treat both as secrets: a leaked environment snippet or preview link exposes unreleased tags. Actions, Reset Link invalidates the old authorisation code and any installed snippets for that environment, so plan the snippet update before resetting.

Server-side tagging

Server containers process measurement data on a server you control, typically Cloud Run in your own Google Cloud project, with clients that claim incoming requests and tags that forward data on. Google recommends running the tagging server on a first-party domain in production mode. Server-side tagging reduces what runs in the browser and lets you shape data before it reaches vendors, but it adds a cloud workload with its own service account, IAM and logs, which must be hardened like any other. See the Google Cloud IAM and Service Accounts Guide.

Linked products

Tags for Google Analytics 4, Google Ads and third-party pixels decide what data leaves the browser. A tag that sends form fields or URL parameters to a vendor is a data protection issue as well as a security one: see the Google Analytics 4 Security guide for the receiving side.

Limiting what a container can do

Access controls protect the GTM account. Page side restrictions protect the website when those controls fail, because they live in your own HTML, under your normal code review, and the container cannot change them.

Allowlists and blocklists

Push gtm.allowlist and gtm.blocklist into the data layer before any tags fire. Entries are type IDs (for example html for Custom HTML, img for Custom Image) or classes. The lists override container configuration, and blocklists override allowlists.

Custom templates and template policies

Google recommends moving from allowlists to custom templates with policies. Templates run sandboxed JavaScript that must declare permissions. Policies, registered on the page with gtag('policy', permissionId, function), can reject a permission request, for example allowing inject_script only for an exact approved URL or prefix, or send_pixel only to approved hosts. A deny-all policy must still allow read_event_data, read_container_data and configure_google_tags or Google measurement stops. Policies can be scoped to one container by checking containerId.

For login, account recovery and payment pages, the strongest control is not to load the container at all. Where it must load, block customScripts and non-Google classes and pair that with a Content Security Policy. The Content Security Policy Guide covers the header side.

Logging and detection

GTM keeps a version for every publish, and the Versions page shows when each version was live and who published it. That is the primary audit trail. It is not streamed anywhere by default, so use the API with tagmanager.readonly to poll it.

• Unexpected publish: a new live version outside your release window, by an agency account, or with no approval request.
• High risk content: new or changed Custom HTML tags or Custom JavaScript variables, new script or pixel destinations, obfuscated code, or tags firing on checkout and login triggers.
• Access changes: new Administrators, new Publish grants, and grants to consumer domains. Compare user lists from the API against an approved list weekly.
• Setting changes: the 2-step verification requirement turned off, new environments, or environment links reset.
• Browser side evidence: CSP violation reports and script change monitoring on payment pages catch a malicious tag even if GTM logs are missed.

A compromised publisher account maps to ATT&CK T1078.004 Cloud Accounts; malicious script served to visitors maps to T1189 Drive-by Compromise and, when it captures sessions, T1185 Browser Session Hijacking. For response steps when injected script is found, use the Web Skimming Incident Playbook: republish the last known good version first, then rotate the compromised identity and remove unknown users.

Metrics:

• Users with Publish per container (target: a named handful).
• Percentage of publishes that passed approval or a documented review (target 100 percent).
• Containers with the 2-step verification requirement enabled (target 100 percent).
• Custom HTML tags per container, trending down as templates replace them.
• Mean time from unexpected publish to detection.

Hardening baseline

1. Inventory: list every GTM account and container, the sites and apps that load each one, Administrators, publishers, agencies, service accounts and environments.
2. Ownership: move any agency owned account under your organisation; keep two or three internal Administrators on managed accounts.
3. 2-step requirement: enable it on every account and confirm consumer accounts with access have 2-step verification on.
4. Permissions: reduce Publish to a small group, give agencies Edit, and remove direct grants left behind by group changes.
5. API access: replace broad scopes with the narrowest per job, store keys in a secrets manager, and start a read only drift monitor.
6. Page restrictions: deploy blocklists or template policies first on payment, login and account pages, in preview, then in production.
7. Change process: require a version name and description on every publish, a reviewer for Custom HTML, and a release window.
8. Test and roll back: test restrictions in a staging environment with preview mode and Tag Assistant, which reports the permission a policy blocked. If production tags break, remove the page restriction through your normal deployment or republish the previous container version from Versions.

Small sites with one container can reach a good position with two Administrators, the 2-step requirement and a blocklist on checkout. Large estates should manage containers through the API from source control, use GTM 360 approvals, and treat the container like any other deployable artefact.

Common misconfigurations

• Agency owns the account: when the relationship ends, your production script supply is controlled by a third party, and you may not be able to remove them.
• Everyone has Publish: the Edit and Approve split exists but is ignored, so any compromised marketing account can deploy code.
• 2-step requirement left off: a phished password on any account with Edit and Publish can add a Custom HTML skimmer.
• Container on payment pages with no restrictions: the container runs with full page access where card data and credentials are entered, against the intent of PCI DSS requirement 6.4.3.
• Single Administrator: an unavailable Administrator leaves no one able to remove a malicious user quickly.
• Old environment snippets and preview links: left on test servers or shared in tickets, they expose unreleased tags and are rarely reset.

Framework mapping

Practitioner checklist

• The GTM account is owned by your organisation with two or three internal Administrators on managed accounts.
• The 2-step verification requirement is enabled on every account.
• Publish is limited to named people; agencies hold Edit unless a contract and review cover Publish.
• Direct container grants are reviewed every 90 days, not only group membership.
• API automation uses the narrowest scopes, with keys in a secrets manager and owners recorded.
• Payment, login and account pages either do not load the container or enforce a blocklist or template policy plus CSP.
• Every published version is diffed against a baseline and unexpected publishes alert the web security team.
• A rollback runbook names who republishes the last known good version and how fast.

Standards and references

• Google: User permissions in Tag Manager
• Google: Tag Manager and 2-step verification
• Google for Developers: Restrict tag deployment
• Google for Developers: Custom template policies
• Google: Publishing, versions and approvals
• Google for Developers: Tag Manager API authorisation
• Google for Developers: Server-side tagging introduction
• Google: Environments in Tag Manager

Related NHI Mgmt Group resources: Third-Party JavaScript Management Guide · Web Skimming Incident Playbook · Google Analytics 4 Security · Content Security Policy Guide