Google Tag Manager CSP misconfigurations enable WAF and CSP bypasses, Raxis warns

Security researcher Ryan Chaplin of penetration testing firm Raxis has documented how Content-Security-Policy (CSP) rules loosened to accommodate Google Tag Manager can be turned against the sites they are meant to protect, defeating both CSP and web application firewall (WAF) defenses. In a post published on dev.to, originally on the Raxis blog on February 10, 2026, Chaplin writes that the pattern appeared repeatedly during client penetration tests, with unsafe directives added so Google Analytics and third-party vendor tags could keep functioning. He says parts of the research were submitted to Google's bug bounty program, which awarded him an honorable mention and swag.

How the CSP gets weakened

A CSP tells a browser which content a page may load and execute, and it is one of the primary defenses against cross-site scripting (XSS). Chaplin demonstrates with a deliberately vulnerable test application that reflects a URL parameter straight into the page. A nonce-based policy stops the classic payload: the server generates a fresh random value for each response, and scripts without that value are refused. An attacker who cannot predict the nonce cannot make injected code execute.

That approach was historically painful to deploy, because scripts loaded dynamically by trusted code were blocked too, forcing teams to generate hashes for every third-party library. The strict-dynamic directive fixed this by letting trust flow from a nonce-approved script to the scripts it loads. Safari was the last browser to adopt it, in 2021.

Google's Tag Manager documentation recommends a nonce, and Chaplin confirms a strict nonce policy does block his test payload. It also breaks GTM's Custom HTML and Custom JavaScript tags, which organizations often need for analytics and sometimes for cookie-consent handling that carries legal weight. According to Chaplin, Google's guidance discourages unsafe-inline but then hands developers the exact directive to add and where to place it, with no mention of strict-dynamic. Tech bloggers amplified the shortcut, and he says most third-party GTM setup guides now simply instruct administrators to include unsafe-inline or even unsafe-eval.

Turning the exemption into an attack

Once a policy drops the nonce and keeps unsafe-inline, the protection collapses. A naive script-tag injection still fails, which can make the configuration look safe, but running the script through an image tag instead executes the same XSS payload.

The GTM-specific allowlist makes the situation worse. Google serves user-defined tag code from googletagmanager.com, so an attacker can place malicious JavaScript on a domain the CSP already trusts. Chaplin sketches an attack against a typical e-commerce application: target admin accounts once per session to steal authentication tokens from a logs page where activity is less likely to be noticed, capture card numbers entered by regular users on the billing page, and exfiltrate the collected data to an external domain. The post also includes a section on bypassing a Cloudflare WAF with the same GTM technique.

Not limited to Google Tag Manager

Chaplin stresses that GTM is an illustration, not the boundary of the problem. Any platform that lets users upload or host content creates the same exposure when developers allow it through a CSP with unsafe directives.

What the post recommends

The remediation section supplies configuration snippets for a .NET Blazor Server application and an nginx.conf file. The direction Chaplin points to throughout is to keep server-generated nonces in force and let strict-dynamic extend trust to the scripts GTM genuinely needs, rather than stripping the nonce in favor of unsafe-inline.

Why it matters

CSPs and WAFs are treated as core controls against XSS, and this research shows both can be quietly neutralized by a line or two of policy added to keep a marketing tool working. The failure mode is institutional: it originates in vendor documentation, is amplified by widely read tutorials, and produces policies that look effective because the obvious attack fails. And because Google serves attacker-influenced JavaScript from a domain most sites already trust, domain reputation alone cannot justify the exemption. Teams running GTM, or any third party that hosts user content, should audit their policies for unsafe-inline and unsafe-eval, confirm that nonces are actually enforced, and treat script-source allowlists as part of their attack surface.