Has publicado una landing, conectado Google Tag Manager y añadido un formulario para captar leads. Poco después, el equipo de seguridad avisa de que una campaña podría estar inyectando código sospechoso, o de que el formulario redirige a un dominio que nadie reconoce. Marketing ve una anomalía en la medición y desarrollo encuentra errores en la consola del navegador.
La pregunta aparece enseguida: ¿qué es CSP y cómo puede proteger la web sin romper las campañas? CSP, siglas de Content Security Policy, es una política que el servidor entrega al navegador para indicar qué scripts, imágenes, conexiones, estilos e iframes puede aceptar. Bien configurada, añade una barrera contra inyecciones de código y ayuda a mantener bajo control el ecosistema técnico de una página, incluidos los recursos que utiliza el first-party data en marketing.
Tabla de contenido
- Por qué tu sitio web necesita una capa extra de protección
- Qué es CSP y cómo la entiende tu navegador
- Las directivas que de verdad importan en una política CSP
- Dos ejemplos reales de cabeceras CSP que puedes comparar
- Errores frecuentes al activar CSP y cómo evitarlos
- Cómo desplegar CSP sin romper tu web
- Checklist final y siguientes pasos en seguridad web
Por qué tu sitio web necesita una capa extra de protección
Un navegador ejecuta los recursos que la página solicita. Si un atacante consigue introducir HTML o JavaScript mediante un formulario mal validado, un comentario, un parámetro de URL o una integración vulnerable, el navegador puede tratar ese código como parte legítima del sitio. Ese escenario se conoce como XSS, o cross-site scripting, y puede exponer sesiones, modificar contenido o enviar datos a un destino controlado por terceros.
HTTPS resuelve otro problema. Cifra la comunicación entre el usuario y el servidor, pero no decide qué script puede ejecutarse dentro de la página una vez que el contenido llega al navegador. Una conexión segura puede transportar tanto código legítimo como código inyectado. Por eso HTTPS y CSP cumplen funciones distintas y deben trabajar juntas.
Idea clave: HTTPS protege el trayecto. CSP limita lo que el navegador permite ejecutar al llegar a destino.
CSP convierte esa decisión en reglas explícitas. La cabecera Content-Security-Policy puede indicar que los scripts solo deben cargarse desde el propio dominio o desde proveedores concretos. Si aparece un recurso que no coincide con la política, el navegador puede bloquearlo. Esa restricción reduce directamente la superficie de ataque XSS, porque una inyección no obtiene automáticamente permiso para ejecutar código.
La política también ayuda frente a otros riesgos. frame-ancestors puede impedir que tu sitio se cargue dentro de un iframe no autorizado, una defensa importante contra clickjacking. Las directivas de conexión limitan adónde puede enviar datos el navegador, algo relevante para formularios, APIs y herramientas de analítica.
El reto está en que una web de marketing rara vez depende de un solo origen. Analytics, píxeles, gestores de etiquetas, reproductores, chats, formularios y pasarelas necesitan permisos distintos. Por eso una CSP efectiva no consiste en bloquearlo todo, sino en identificar qué utiliza realmente tu sitio y autorizar únicamente esos recursos.
Qué es CSP y cómo la entiende tu navegador
CSP es una política de seguridad aplicada por el navegador, normalmente enviada por el servidor mediante una cabecera HTTP. Antes de cargar o ejecutar un recurso, el navegador compara su origen y su tipo con las reglas recibidas. Si el recurso no está permitido, lo bloquea o registra una violación, según el modo de la política.
La analogía más útil es la de un edificio. Tu web es el edificio y CSP es la lista de visitantes autorizados en la entrada. No basta con que alguien conozca la dirección. Tiene que aparecer en la lista correspondiente, ya sea para ejecutar JavaScript, cargar una imagen o abrir una conexión.
La sintaxis se compone de directivas separadas por punto y coma. Cada directiva define una categoría de recurso y sus orígenes permitidos:
Content-Security-Policy: default-src 'self'
default-src funciona como regla general y 'self' significa el mismo origen que sirve la página. Una política más detallada podría tener esta forma:
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.tu-analytics.com; img-src 'self' data:; connect-src 'self'
En este caso, el sitio acepta recursos propios, JavaScript desde un CDN concreto, imágenes propias o embebidas como datos, y conexiones hacia una API de analítica determinada. Los orígenes deben describirse con precisión. Un comodín amplio puede ser cómodo durante una prueba, pero dificulta saber qué dependencia tiene permiso para actuar.
La documentación de CSP en MDN recomienda un despliegue progresivo. Content-Security-Policy-Report-Only observa la política y genera informes sin bloquear los recursos. Es el modo adecuado para descubrir dependencias legítimas antes de aplicar restricciones.
CSP no sustituye la validación de entradas, la sanitización, HTTPS, la gestión segura de sesiones ni las actualizaciones del servidor. Añade una decisión de control en el navegador. La aplicación debe seguir evitando que datos proporcionados por usuarios se conviertan en código ejecutable.
Las directivas que de verdad importan en una política CSP
Una política práctica empieza por distinguir el tipo de recurso que necesita cada herramienta. No todos los permisos resuelven el mismo problema, y añadir un dominio a la directiva equivocada no hará que una integración funcione.
La regla general y el JavaScript
default-src actúa como red de seguridad para categorías que no tienen una directiva específica. Usar default-src 'self' establece una base restrictiva, aunque las directivas concretas deben definir después las excepciones necesarias.
script-src controla de dónde puede cargarse y ejecutarse JavaScript. Puede incluir el dominio propio y un proveedor concreto, por ejemplo El punto delicado son'unsafe-inline'y'unsafe-eval'`. El primero permite scripts inline y el segundo habilita la evaluación dinámica de código. Ambos pueden ser necesarios para aplicaciones antiguas, pero reducen el valor defensivo de CSP frente a XSS. Antes de aceptarlos, conviene migrar scripts inline a archivos externos y revisar qué biblioteca exige evaluación dinámica.
Recursos visuales, conexiones y marcos
img-src controla imágenes, incluidos píxeles de medición. Una configuración puede permitir 'self', data: y un CDN específico, pero no debería aceptar cualquier origen por comodidad.
connect-src limita destinos de fetch, XHR, EventSource y WebSocket. Si una herramienta de analítica carga correctamente pero no puede enviar eventos, esta directiva suele ser una de las primeras que hay que revisar. Un origen como ` debe añadirse solo si forma parte real del flujo.
frame-src controla qué contenido puede cargar la página dentro de un iframe. Es relevante para una pasarela de pago, un vídeo o una creatividad de campaña. En cambio, frame-ancestors indica quién puede insertar tu propia página en un marco y ayuda a prevenir clickjacking. No son intercambiables.
object-src 'none' desactiva objetos y plugins heredados que rara vez son necesarios en una web moderna. Es una restricción sencilla con poco impacto en sitios que ya no dependen de ese tipo de contenido.
| Directiva | Qué protege | Ejemplo de valor |
|---|---|---|
default-src |
Recursos no cubiertos por otra regla | 'self' |
script-src |
JavaScript ejecutable | `'self' |
img-src |
Imágenes y píxeles | `'self' data: |
connect-src |
APIs, analítica y WebSocket | `'self' |
frame-src |
Contenido cargado en iframes | `'self' |
frame-ancestors |
Sitios autorizados a enmarcar tu web | 'self' |
object-src |
Plugins y objetos heredados | 'none' |
La política debe reflejar el inventario técnico real. Autorizar un dominio general porque “pertenece al proveedor” puede abrir más superficie de la necesaria, especialmente cuando ese dominio sirve múltiples productos.
Dos ejemplos reales de cabeceras CSP que puedes comparar
Una landing sencilla suele tener menos dependencias que un ecommerce. Si solo sirve recursos propios, carga un formulario y utiliza un proveedor concreto para medición, puede comenzar con una política relativamente estricta:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; connect-src 'self' form-action 'self'; frame-ancestors 'self'; object-src 'none'
Esta cabecera permite scripts propios, imágenes propias o codificadas como datos y conexiones hacia una API identificada. form-action 'self' limita los destinos a los que pueden enviarse formularios. El uso de 'unsafe-inline' en style-src puede ser una concesión temporal para estilos generados por un CMS, pero conviene reducirlo si la plataforma lo permite.
Un ecommerce necesita más piezas. Este ejemplo es deliberadamente ilustrativo, porque los dominios reales deben salir de una auditoría del sitio:
Content-Security-Policy: default-src 'self'; script-src 'self' style-src 'self' 'unsafe-inline' img-src 'self' data: connect-src 'self' frame-src 'self' frame-ancestors 'self'; object-src 'none'
Aquí aparecen cdnjs y jsDelivr porque algunas tiendas los usan para bibliotecas externas. script-src autoriza scripts de Tag Manager, Google Analytics y Meta Pixel, mientras connect-src permite que esos sistemas envíen eventos. frame-src incorpora una pasarela de pago, un reproductor o una campaña embebida.
| Directiva | Política estricta mínima | Política ecommerce en producción |
|---|---|---|
default-src |
'self' |
'self' |
script-src |
'self' |
'self' más CDNs, Tag Manager, Google y Meta |
img-src |
'self' data: |
'self' data: más endpoints de medición |
connect-src |
'self' más una API |
APIs propias, analítica y publicidad |
frame-src |
No necesario o 'self' |
Pasarela, vídeo y campañas autorizadas |
frame-ancestors |
'self' |
'self' |
object-src |
'none' |
'none' |
La segunda parece más permisiva porque contiene más excepciones, pero sigue siendo más segura que no tener ninguna política. La diferencia está en que los permisos son explícitos y revisables, en lugar de dejar que cualquier recurso solicitado por la página se ejecute.
Errores frecuentes al activar CSP y cómo evitarlos
Una política puede ser técnicamente correcta y aun así interrumpir una campaña. El problema suele aparecer cuando el equipo autoriza el script principal, pero olvida las conexiones secundarias o los iframes que la herramienta necesita.
Analytics bloqueado
Google Analytics, Meta Pixel o Tag Manager pueden dejar de registrar actividad si sus scripts no están en script-src. Incluso cuando el script se carga, los eventos pueden fallar porque sus destinos no aparecen en connect-src o porque los píxeles de imagen no están autorizados en img-src.
El diagnóstico empieza en la pestaña Network del navegador. Busca las solicitudes de medición y comprueba si reciben errores relacionados con CSP. Después, revisa los mensajes de la consola y añade los orígenes exactos que el flujo necesita, no un comodín que abarque todo internet. Una revisión de analítica de datos en marketing ayuda a relacionar los bloqueos técnicos con la pérdida de señales de campaña.
Iframes que muestran una pantalla en blanco
Una pasarela de pago, un vídeo o una creatividad embebida pueden desaparecer si falta frame-src. El visitante ve una zona vacía, mientras el equipo de marketing puede asumir que el problema está en la campaña o en el proveedor.
Reproduce el recorrido completo, desde la landing hasta el pago o el contenido incrustado. Anota el origen exacto que el navegador rechaza y autorízalo únicamente en frame-src. Si el problema consiste en que otro sitio intenta insertar tu página, revisa frame-ancestors, que cumple una función diferente.
Bloqueo inmediato sin observación previa
Activar la política bloqueante desde el primer minuto convierte cada dependencia olvidada en una incidencia de producción. La consola mostrará el error, pero el equipo puede tardar en relacionarlo con un cambio de cabecera, sobre todo si varias campañas se ejecutan a la vez.
Content-Security-Policy-Report-Only permite observar violaciones antes de bloquear. Recoge los recursos legítimos que todavía no están contemplados y separa esos casos de solicitudes sospechosas. La política definitiva debe llegar después de esa revisión, con marketing, desarrollo y seguridad validando juntos los recorridos críticos.
Cómo desplegar CSP sin romper tu web
El despliegue seguro es incremental. Empieza con una política de observación y un endpoint capaz de recibir los informes de violación. Durante el periodo de revisión, comprueba páginas de captación, formularios, checkout, consentimientos, vídeos, chats y etiquetas publicitarias.
Un flujo de trabajo coordinado
- Observar primero: Sirve
Content-Security-Policy-Report-Onlycon las directivas iniciales y registra los informes. - Clasificar cada aviso: Separa recursos legítimos, dependencias obsoletas y solicitudes que no deberían existir.
- Refinar permisos: Añade solo los orígenes necesarios a
script-src,style-src,connect-src,img-srcyframe-src. Elimina comodines que ya no hagan falta. - Aplicar y monitorizar: Cambia a
Content-Security-Policycuando los recorridos estén validados y observa los primeros errores en producción.
Marketing debe proporcionar el calendario de campañas y las páginas que no pueden fallar. Desarrollo puede inspeccionar la consola, el panel Network y los informes del navegador. Seguridad debe revisar si cada excepción tiene una justificación y un propietario.
Antes de publicar cambios, prueba también scripts externos con Subresource Integrity, cuando el proveedor y el recurso lo permitan. Esta medida comprueba que el archivo recibido coincide con la versión esperada y complementa la restricción de orígenes de CSP.
La revisión de conversiones mejoradas de Google Ads debe formar parte del inventario de medición cuando tu implementación utilice formularios, etiquetas o conexiones adicionales. El objetivo no es crear una lista enorme de dominios, sino conseguir que cada permiso tenga una razón técnica verificable.
Checklist final y siguientes pasos en seguridad web
CSP funciona mejor cuando el equipo la trata como una política mantenida, no como una cabecera que se configura una vez y se olvida. Los cambios de CMS, nuevas etiquetas, rediseños, proveedores de pago y campañas embebidas pueden introducir recursos que antes no existían.
Revisión rápida para esta semana
- Confirmar la cabecera: Comprueba que el servidor entrega
Content-Security-Policyen las páginas relevantes. - Revisar la base: Verifica que
default-srcyscript-srccubren únicamente los orígenes necesarios. - Probar el negocio: Completa formularios, pagos, vídeos, iframes y consentimientos desde un navegador real.
- Validar la medición: Comprueba que Google Analytics, Meta Pixel y Tag Manager siguen enviando sus eventos.
- Revisar informes: Mantén un endpoint de reportes y asigna responsables para analizar las alertas.
También conviene revisar cabeceras complementarias como Strict-Transport-Security, X-Frame-Options y Permissions-Policy. Cada una aborda un aspecto diferente, así que CSP no debe presentarse como sustituto de parches, autenticación sólida, control de accesos, validación de entradas o formación del equipo.
Mide el comportamiento de la página antes y después de aplicar cambios. Observa errores de JavaScript, carga de etiquetas, formularios y Core Web Vitals. Una política bien ajustada debería mejorar el control sin convertirse en una fuente silenciosa de fallos para usuarios o campañas.
El siguiente paso es concreto: publica primero Content-Security-Policy-Report-Only, revisa las violaciones durante una semana y documenta cada excepción aprobada. Después, activa la política bloqueante en las páginas validadas y conserva una revisión periódica cuando marketing añada nuevas herramientas.
Si tu equipo necesita auditar dependencias, ordenar permisos CSP y proteger la medición de campañas sin perder conversiones, Optimiza Growth Agency puede ayudarte a coordinar analítica, automatización de marketing y adquisición digital. Visita su web para valorar un diagnóstico técnico conectado con tus objetivos de crecimiento.