La Content Security Policy (CSP) es una política de seguridad web que controla qué scripts, recursos y conexiones pueden ejecutarse en una página. Su objetivo principal es proteger las webs de vulnerabilidades, como los ataques de Cross-Site Scripting (XSS), asegurando que solo los recursos confiables sean cargados y ejecutados. En el contexto de Google Tag Manager (GTM), la CSP puede bloquear la ejecución de scripts de seguimiento si no están explícitamente permitidos, lo que puede interrumpir la recopilación de datos y afectar la precisión del tracking.
CSP, Navegadores y Tracking: ¿Por qué ahora todo “deja de funcionar”? (Y no es culpa de GTM)
La CSP y el nuevo paradigma de seguridad en navegadores
En los últimos meses, muchos equipos de Analítica, SEO, CRO y optimización de conversiones han detectado un problema aparentemente inexplicable: implementaciones que funcionaban correctamente durante meses —o incluso años— dejan de enviar datos de un día para otro. Google Tag Manager está bien configurado, los eventos se disparan, pero los datos no llegan a las herramientas de análisis.
Si has visto errores en el Debug View de GTM o en la consola del navegador indicando bloqueos de recursos, es probable que ya hayas identificado el verdadero origen del problema: la Content Security Policy (CSP).
Este fenómeno no es aislado ni puntual. Es una tendencia estructural impulsada por los cambios que los navegadores han implementado —especialmente Chrome— que está alterando de forma significativa cómo debemos plantear el tracking, la atribución de conversiones y la optimización de datos.
El contexto: no ha cambiado GTM, han cambiado los navegadores
Es fundamental aclararlo desde el inicio: GTM no ha cambiado. Lo que ha cambiado es cómo los navegadores aplican la seguridad.
En versiones recientes de Chrome (120+), se han endurecido las políticas de seguridad como la CSP, lo que ha llevado a:
- Mayor restricción sobre scripts inline
- Bloqueo de
eval() - Refuerzo de mecanismos como Trusted Types
- Mayor visibilidad de errores en la consola del navegador
Antes, muchas implementaciones funcionaban «por tolerancia». Hoy, solo funciona lo que está correctamente definido dentro de las reglas de seguridad del navegador, lo que afecta directamente a la visibilidad de tus píxeles y scripts de seguimiento.
¿Qué es la CSP y por qué impacta directamente al tracking?
La Content Security Policy (CSP) es una cabecera HTTP que actúa como un control de acceso para la ejecución de código JavaScript y la carga de recursos externos en tu página. Funciona como un portero que decide qué scripts pueden ejecutarse y desde qué dominios.
El punto clave para el tracking y la optimización de conversiones es este:
- GTM no ejecuta todo directamente, sino que carga scripts externos (Google Analytics, Meta Pixel, etc.)
- Esos scripts necesitan permisos explícitos en la política CSP
- Si no están definidos → el navegador los bloquea sin avisar al usuario
Aquí el diagrama de flujo que explica qué ocurre exactamente cuando un usuario carga tu página:
Esto explica el síntoma más frecuente que reportan los equipos: «los eventos se disparan en GTM, pero no llegan datos a las plataformas de análisis». El evento se ejecuta, pero la conexión con los destinos está bloqueada por la CSP.
Las tres capas del tracking moderno: lo que ya no controlas
El tracking web ya no depende solo de GTM. Depende de tres capas que, en gran medida, están fuera de tu control directo:
La CSP actúa como el punto de control central de esas tres capas. Si no está correctamente configurada, cualquier cambio en el navegador del usuario o en un servicio externo puede romper el flujo de datos completo.
¿Por qué estamos viendo más problemas (y por qué seguirán aumentando)?
Este no es un problema puntual sino una transformación estructural. Hay tres razones que lo explican:
1. Endurecimiento de la seguridad en los navegadores
Los navegadores, especialmente Chrome, están priorizando la seguridad del usuario sobre la flexibilidad técnica. Esto implica:
- Menos tolerancia a configuraciones incorrectas
- Mayor cumplimiento de los estándares W3C
- Bloqueo activo de scripts no permitidos (ya no hay «errores silenciosos»)
2. Complejidad creciente del ecosistema de tracking
Las páginas web actuales suelen integrar múltiples plataformas de análisis y publicidad, cada una con sus propios scripts y dominios: GTM, GA4, Google Ads, Meta Pixel, TikTok, herramientas de experimentación como VWO u Optimizely, CDPs, chatbots, etc. Cada servicio nuevo que añades requiere que su dominio esté autorizado en la CSP. La CSP ya no es algo estático: es un sistema vivo que debe crecer con tu stack.
3. Diferencias entre navegadores
Los navegadores no aplican la CSP de forma idéntica, lo que genera inconsistencias difíciles de diagnosticar:
| Navegador | Nivel de Restricción CSP | Impacto Común | Fuente |
|---|---|---|---|
| Chrome | Muy alto | Bloqueo de recursos no permitidos (scripts inline, eval(), etc.) |
La implementación de CSP ha sido reforzada desde Chrome 120+. Esto incluye la restricción en los scripts inline, el uso de unsafe-eval, y bloqueos agresivos de recursos que no están explícitamente permitidos. |
| Edge | Alto | Menos bloqueos, aunque se observan algunos problemas con ITP (Intelligent Tracking Prevention) | Microsoft Edge ha adoptado políticas similares a las de Chrome, pero con algunos ajustes en cómo maneja la privacidad del usuario y los bloqueos de cookies. No aplica las restricciones de forma tan estricta como Chrome. |
| Safari | Alto + Privacidad | Restricciones más estrictas con ITP y bloqueos de scripts inline | Safari ha implementado Intelligent Tracking Prevention (ITP), lo que provoca bloqueos en los scripts de tracking, y su política de seguridad incluye restricciones adicionales a los scripts inline y el uso de eval(). |
| Firefox | Alto | Errores de ejecución más técnicos y menos visibles | Firefox se aplica CSP de manera similar a Chrome, pero tiene un enfoque más técnico y menos visual en cuanto a los errores. La ejecución puede fallar sin que el usuario vea errores evidentes |
Un mismo tracking puede funcionar correctamente en Chrome y fallar en Safari, generando inconsistencias en los datos que afectan directamente a la fiabilidad de tus pruebas A/B y experimentos de optimización.
¿Qué está bloqueando realmente la CSP?
En la práctica, hay tres tipos de conflictos principales que debes conocer:
1. Scripts externos
Los scripts cargados desde dominios externos —como GTM o GA4— deben estar explícitamente permitidos en la directiva script-src de tu CSP:
script-src https://www.googletagmanager.com https://www.google-analytics.com
Si el dominio no está incluido, el script no se ejecuta.
2. Scripts inline (muy comunes en GTM)
Son los Custom HTML Tags o cualquier código JS añadido directamente en el <head>. Para permitirlos tienes tres opciones con distintos niveles de seguridad:
unsafe-inline→ fácil de implementar, pero debilita la seguridad de la CSPnonce→ recomendado; genera un token único por carga de página que autoriza el scripthash→ técnicamente correcto, pero poco práctico cuando los scripts cambian con frecuencia
En la mayoría de implementaciones con GTM, la solución recomendada es nonce, que permite autorizar scripts específicos sin abrir la puerta a cualquier inline.
3. Evaluación dinámica (eval)
Relacionado con el uso de Variables JS personalizadas en GTM. Si la CSP no incluye unsafe-eval, esas variables devolverán undefined aunque el código sea sintácticamente correcto. Es un error muy difícil de diagnosticar porque no falla de forma evidente.
¿Cómo identificar y corregir problemas de CSP?
Los bloqueos por CSP son visibles en las herramientas de desarrollo del navegador:
- Abre la consola del navegador (F12)
- Ve a la pestaña «Consola» y busca errores con el prefijo
Content Security Policy - Identifica qué recursos están siendo bloqueados y desde qué directiva
- Ajusta la política CSP para incluir los dominios relevantes en
script-src,img-srcyconnect-src
Apóyate en Inteligencia Artificial más técnica (ej. Claude) Esta es una excelente práctica actual. Cuando entres a la consola de desarrollador (F12) de tu navegador, verás una lluvia de errores rojos de CSP. Puedes exportar o copiar todos esos dominios bloqueados y usar un modelo como Claude con este prompt: «Actúa como experto en seguridad web y analítica. Aquí tienes los errores de CSP que me da la consola de mi web al visitar mi web y al cargar por Google Tag Manager mis píxeles de conversión . Necesito que me generes las directivas script-src, img-src y connect-src necesarias para pasárselas al equipo de IT. Organízalas por dominio de manera ordenada. Usa wildcards (*) si sobrepasas los caracteres permitidos por una CSP estándar.»
(Consejo Top: prueba tus webs también en la conversión, suele haber más servicios y bloqueos enfuncionamiento)
Para ver los bloqueos pincha en los iconos de error (aspa X), que muestran dos formas de ver los mensajes:
Probar los cambios sin tocar el servidor: Local Overrides
Antes de modificar la configuración del servidor, puedes probar cambios en la CSP directamente en el navegador usando la función de Local Overrides de Chrome DevTools:
- Abre DevTools (F12) → pestaña Red
- Localiza la cabecera
Content-Security-Policyen la respuesta - Anula su valor localmente para testear si los recursos se cargan correctamente
- Verifica los resultados en tiempo real
Esto te permite validar la solución antes de desplegarla, sin riesgo de romper nada en producción.
- Chrome DevTools: Local Overrides — tutorial oficial para testear cambios de cabeceras sin modificar el servidor
Reflexión final: el tracking ha entrado en una nueva fase
El tracking web ya no es solo una cuestión de herramientas y configuraciones. Está directamente relacionado con la arquitectura de seguridad de los navegadores y la forma en que las IAs y los motores de búsqueda evalúan la calidad técnica de un sitio.
En el contexto actual —donde los modelos de lenguaje y los rastreadores de IA indexan contenido basándose también en señales técnicas de fiabilidad— una web con errores de CSP que impiden la carga correcta de scripts puede ser interpretada como un entorno técnicamente inconsistente.
Esto no afecta solo a tus datos de analítica: afecta a la coherencia de las señales que emite tu sitio hacia cualquier sistema que lo evalúe, ya sea un buscador tradicional o un motor de IA. Es decir, si no configuramos correctamente estas políticas, afectamos tanto la precisión de nuestros datos como la eficacia de nuestras estrategias de experimentación, de CRO y, en última instancia, la visibilidad del sitio en entornos de búsqueda generativa.
Fuentes y recursos
Documentación oficial
- Content Security Policy — MDN Web Docs — referencia técnica completa sobre la especificación CSP
- Guía CSP para Google Tag Manager — Google Developers — configuración específica para GTM
- Content Security Policy — web.dev — guía práctica de Google para implementar CSP correctamente
Herramientas de diagnóstico y auditoría
- CSP Evaluator — herramienta de Google para analizar la seguridad de una política CSP
- Security Headers — auditoría completa de cabeceras HTTP de seguridad
Recursos técnicos complementarios
- Chrome DevTools: Local Overrides — tutorial oficial para testear cambios de cabeceras sin modificar el servidor
- W3C CSP Level 3 Specification — especificación oficial del estándar
- Trusted Types — web.dev — sobre el mecanismo Trusted Types que Chrome está reforzando
