Content Security Policy es la cabecera HTTP que decide, script a script, qué código puede ejecutarse en una web y a qué dominios puede enviar datos. Sin ella, un script inyectado en un formulario de contacto o de pago corre con la misma confianza que el código propio de la página. Esto no afecta solo a quien vende online: un formulario de captación de leads filtrado perjudica tanto como un dato de tarjeta robado. Esta pieza explica qué controla la cabecera, qué exige ya la normativa de pagos desde 2025 y cómo probarla sin romper las herramientas de analítica y publicidad que usa el equipo de marketing.
Content Security Policy es una cabecera HTTP que le dice al navegador qué dominios pueden cargar scripts, imágenes o enviar datos desde una página; un script inyectado que no esté en esa lista no se ejecuta. Las tiendas online además la necesitan por ley: desde el 31 de marzo de 2025, el Requisito 6.4.3 de PCI DSS 4.0.1 obliga a autorizar e inventariar cada script del formulario de pago.
Qué es Content Security Policy y qué bloquea
La cabecera Content Security Policy viaja en cada respuesta del servidor y el navegador la lee antes de ejecutar una sola línea de JavaScript. En vez de confiar en que el código que llega es el que escribió el equipo de desarrollo, el navegador compara cada recurso -un script, una imagen, una llamada a una API- contra una lista de orígenes permitidos. Lo que no está en esa lista no se ejecuta, aunque el atacante ya haya conseguido insertarlo en la página.
Esto la distingue de un firewall de aplicaciones web: un WAF filtra lo que entra al servidor, y Content Security Policy filtra lo que el navegador del visitante ejecuta una vez la página ya se ha cargado. Son capas distintas y hacen falta las dos, porque la primera no ve nada cuando el script malicioso llega disfrazado de recurso legítimo de un tercero ya autorizado, como una librería de analítica comprometida.
Magecart multiplica por tres sus ataques a tiendas
Magecart es el nombre que se da a los grupos que llevan desde 2015 inyectando scripts de robo de datos en páginas de pago y de contacto. Según el informe de amenazas de Recorded Future, el número de dominios de ecommerce afectados por este tipo de ataque -conocido como formjacking- se triplicó en 2024 respecto a 2023, y solo un grupo, Burunduki, infectó más de 200 tiendas online en el último tramo del año. El objetivo ya no es solo el número de tarjeta: también los campos de nombre, teléfono y correo de un formulario de contacto, que sirven igual para el fraude.
Buena parte de esa ola se apoyó en CosmicSting, una vulnerabilidad de Adobe Commerce y Magento que permitió comprometer webs en masa hasta que llegaron los parches a principios de 2025. En 2026 el vector favorito ya no es un fallo sin parchear, sino un contenedor de Google Tag Manager comprometido: el script malicioso entra disfrazado de una etiqueta de marketing más, la misma vía por la que entra el píxel de conversión. Muchos de esos contenedores llegan a través de un complemento de WordPress sin actualizar, y las vulnerabilidades en plugins de WordPress sin parche siguen siendo la puerta de entrada más repetida: mantenerlos al día es tarea de quien lleva la gestión del WordPress de la empresa, no solo del equipo de marketing que instaló la etiqueta.
Las directivas que forman una política CSP estricta
Una política CSP se declara con directivas, cada una responsable de un tipo de recurso. No hace falta escribirlas todas, basta con las que carguen algo en la página:
- default-src, el valor de respaldo cuando una directiva concreta no se declara.
- script-src, qué dominios pueden servir código JavaScript.
- connect-src, a qué dominios puede llamar la página con fetch, XHR o websockets.
- img-src y font-src, de dónde se cargan imágenes y tipografías.
- object-src, que conviene fijar siempre en none: ahí no hay ningún uso legítimo en una web moderna.
script-src y nonce, el filtro sobre el código
script-src es la directiva que más cuesta ajustar, porque una web corporativa carga código de varios orígenes: el propio, el del gestor de etiquetas y el de algún widget de chat. Permitir ‘unsafe-inline’ para que todo funcione sin fricción equivale a no tener política, porque un script insertado por un atacante también es “inline”. La alternativa es un nonce distinto en cada carga de página -una cadena aleatoria añadida a la cabecera y a la etiqueta script- combinado con ‘strict-dynamic’, que deja que un script ya autorizado cargue a su vez los que necesita sin listarlos todos a mano.
connect-src, el freno a la fuga de datos
connect-src detiene la fuga de datos una vez que un script malicioso ya se ha ejecutado, y es la que más se descuida porque no rompe nada visible al dejarla abierta. Las técnicas de exfiltración de 2026 ya no mandan los datos a un dominio sospechoso, sino por canales WebRTC o por servicios legítimos que actúan como intermediario, precisamente para esquivar una política que solo vigila script-src. Según recoge el OWASP Cheat Sheet de Content Security Policy, una connect-src abierta con el comodín * anula buena parte del resto de la política. Fijar una lista cerrada de dominios -el propio y la pasarela de pago- es lo que convierte la cabecera en una barrera real.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Content Security Policy en el formulario de pago
Content Security Policy dejó de ser una buena práctica opcional para quien cobra con tarjeta. Desde el 31 de marzo de 2025 es obligatoria de hecho: el Requisito 6.4.3 de PCI DSS 4.0.1, la norma que deben cumplir los comercios que aceptan tarjeta, exige controlar cada script de la página de pago, según confirma el PCI Security Standards Council. La norma no dicta la cabecera CSP por su nombre, pero es la forma más razonable de cumplirla. En concreto, exige:
- Autorizar cada script con una justificación de negocio documentada, incluidos los de analítica y los del chat de soporte.
- Comprobar la integridad de cada script, para detectar si alguien lo ha modificado sin permiso.
- Mantener un inventario actualizado de todos los scripts que cargan en esa página.
Requisito 6.4.3, qué exige desde 2025
El Requisito 6.4.3 no se limita a los scripts que escribió el equipo de desarrollo: cubre también la etiqueta de analítica, el píxel de conversión y cualquier librería de un CDN externo, aunque la haya instalado marketing. Quedarse fuera del requisito solo es posible si la empresa demuestra que su página de pago no es susceptible de este ataque, un criterio añadido al cuestionario SAQ A en enero de 2025 que aplica a muy pocos comercios. Para el resto, sin política CSP documentada ni inventario de scripts, el formulario de pago incumple la norma aunque nunca haya sufrido un incidente. Quien no tenga equipo propio para revisarlo puede apoyarse en un servicio de seguridad informática que mantenga el inventario al día.
Cómo probar la política sin romper tu web
Activar Content Security Policy en modo bloqueo desde el primer día es la forma más rápida de tumbar sin querer el formulario de contacto, el vídeo incrustado o la propia campaña de publicidad. La cabecera tiene un modo de prueba pensado justo para eso: Content-Security-Policy-Report-Only aplica las mismas reglas pero no bloquea nada, solo informa -al navegador o a un endpoint propio- de qué habría bloqueado. Conviene dejarla así entre una y dos semanas, revisar los avisos y solo entonces pasar a la cabecera que sí bloquea.
Google Tag Manager y los píxeles que hay que permitir
La mayoría de los avisos en modo prueba no son ataques: son las propias herramientas de marketing, que cargan desde dominios que nadie incluyó en la lista. Google Tag Manager necesita googletagmanager.com y google-analytics.com en script-src y connect-src; el píxel de Meta, connect.facebook.net; el Insight Tag de LinkedIn, snap.licdn.com. Cada campaña nueva -un chat de WhatsApp, un mapa incrustado, un formulario de un proveedor externo- añade un dominio a la lista. Por eso quien gestiona las campañas y quien mantiene la web deben revisar juntos la política antes de cada lanzamiento; una auditoría web periódica es el momento natural para hacerlo.
Preguntas frecuentes sobre Content Security Policy
¿Content Security Policy sustituye al certificado SSL?
No, son capas distintas. El certificado SSL cifra la conexión entre el navegador y el servidor para que nadie la intercepte por el camino; Content Security Policy controla qué código se ejecuta una vez que esa conexión ya ha entregado la página. Hacen falta las dos: una web puede tener SSL y seguir siendo vulnerable a un script inyectado.
¿CSP puede bloquear Google Analytics o los anuncios sin querer?
Sí, y es el fallo más común al activarla. Si el dominio de la herramienta no está en la lista de permitidos, el navegador la bloquea igual que a un script malicioso. Por eso se prueba primero en modo Report-Only, que avisa de los bloqueos sin aplicarlos, antes de pasar a la versión que sí restringe.
¿Qué pasa si una web no tiene ninguna política CSP?
El navegador ejecuta cualquier script que llegue, venga de donde venga. No hay ningún aviso ni ninguna restricción: un script inyectado en un formulario corre con la misma confianza que el código propio de la página, y nadie se entera hasta que aparece el fraude.
¿Es obligatorio Content Security Policy en cualquier web, no solo en tiendas online?
La obligación legal de PCI DSS solo cubre páginas de pago con tarjeta. En cualquier otra web con formularios -contacto, reserva, captación de leads- es una medida recomendada y no exigida, pero el riesgo de robo de datos es el mismo si no se aplica.
