Blog · Magento 2.4+

Google Tag Manager Blocked by CSP in Magento? Here’s How to Fix It

You installed Google Tag Manager, published a container, and… nothing. No events firing, no data in GA4, no errors on the page that anyone would notice unless they opened DevTools. If that’s you, open the browser console. There’s a good chance you’ll see something like:

Refused to load the script 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX'
because it violates the following Content Security Policy directive: "script-src 'self' ..."

This is one of the most common support tickets for stores running Magento 2.4.7+, and it has nothing to do with your GTM setup. It’s Magento’s built-in Content Security Policy quietly blocking the request before it ever reaches Google’s servers.

Why this happens

Magento 2.4+ ships strict CSP headers by default, restricting which domains the storefront is allowed to load scripts, styles, fonts, images, and connections from. Google Tag Manager needs several domains whitelisted to work correctly, and none of them are included out of the box:

If any one of these is missing, GTM can load fine and still fail to actually fire tags, which makes the problem harder to diagnose than a flat-out blocked script.

Option 1: Edit csp_whitelist.xml (the developer route)

Magento’s documented approach is a csp_whitelist.xml file in a custom module, declaring each policy and value:

<csp_whitelist>
    <policies>
        <policy id="script-src">
            <values>
                <value id="gtm" type="host">www.googletagmanager.com</value>
            </values>
        </policy>
        <policy id="connect-src">
            <values>
                <value id="gtm-connect" type="host">www.googletagmanager.com</value>
                <value id="ga-connect" type="host">www.google-analytics.com</value>
            </values>
        </policy>
    </policies>
</csp_whitelist>

This works, but it requires a developer, a deploy, and a cache flush every time marketing wants to add a new tag, pixel, or third-party script inside the container. For a store running frequent campaigns, that turnaround time adds up.

If the XML is in place and GTM is still blocked, see csp_whitelist.xml not working in Magento 2.

Option 2: Disable CSP entirely (don’t do this)

Some guides suggest just switching CSP to report-only mode or disabling it in env.php. This removes the error, but it also removes the protection CSP exists for in the first place — it’s a real defense against injected scripts and data exfiltration on your storefront. Treat this as a last-resort diagnostic step, not a fix.

Option 3: Manage the whitelist from Magento Admin

If your team adds tracking scripts, pixels, or CDNs more than once a quarter, an Admin-managed whitelist removes the deploy cycle entirely. CSP Manager for Magento adds a Whitelist Rules grid under System → Other Settings, so a store admin can add www.googletagmanager.com to script-src and connect-src, scope it to the right store view, and see it take effect without touching code. A built-in Policy Inspector shows you the exact merged policy per store view, so you can confirm the host is live before asking marketing to check GA4.

It also blocks unsafe values like 'unsafe-inline' and * from being added through the form, so opening this up to non-developers doesn’t turn into a security hole.

Checklist to confirm the fix

  1. Open DevTools → Console and reload the storefront page GTM is on.
  2. Confirm there are no more Refused to load errors referencing googletagmanager.com or google-analytics.com.
  3. Use GTM’s Preview mode to confirm tags fire.
  4. Check GA4 Realtime to confirm events are landing.

If step 1 is still showing errors after adding the domains, double-check the store view scope — a rule added to the default scope won’t necessarily apply if the storefront view has its own CSP configuration overriding it.