Resumen: límites de cumplimiento de CSP
- CSP es una defensa nativa del navegador fundamental, pero no proporciona por sí sola el cumplimiento de PCI DSS 4.0.1. El ataque a la cadena de suministro de Polyfill.io de 2024 tuvo éxito en cientos de miles de sitios donde CSP estaba correctamente configurada.
- El límite fundamental es que CSP permite dominios en una lista de confianza, no integridad del código. Si un dominio de confianza se ve comprometido (como le ocurrió a Polyfill.io), CSP sigue permitiendo que el código malicioso se cargue y ejecute.
- PCI DSS 4.0.1 §6.4.3 y §11.6.1 exigen explícitamente capacidades que van más allá de CSP: un inventario de scripts con justificación de negocio, verificación de integridad en cada carga y detección de modificaciones no autorizadas en las páginas de pago.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
¿Qué es una Política de Seguridad de Contenido (CSP)?
Una Política de Seguridad de Contenido (CSP) es una cabecera de respuesta HTTP que indica a los navegadores qué fuentes de scripts, hojas de estilo y frames están autorizados a cargarse. Mitiga el XSS bloqueando scripts en línea no autorizados y cargas externas no permitidas. CSP es una base necesaria, pero no detecta anomalías de comportamiento en scripts autorizados, no supervisa lo que hacen esos scripts en tiempo de ejecución, ni satisface el requisito de PCI DSS 6.4.3 de disponer de un inventario de autorización de scripts con justificación de negocio.
La Política de Seguridad de Contenido (CSP) es una función de seguridad que ofrecen los navegadores web y que el propietario de un sitio web puede usar para definir un conjunto de reglas que controlan qué recursos (p. ej., scripts, estilos, imágenes) puede cargar y ejecutar el navegador. A esto lo llamamos el lado del cliente, que se encuentra al final de la cadena de suministro web.
Cuando está correctamente configurada, ayuda a prevenir una amplia gama de ataques. Pero esas tres primeras palabras marcan toda la diferencia.
Puede ayudar a prevenir el cross-site scripting (XSS): al restringir las fuentes desde las que pueden cargarse los scripts, CSP bloquea los scripts maliciosos inyectados en una página web. Por ejemplo, si una política CSP especifica script-src 'self', solo pueden ejecutarse scripts del propio dominio del sitio web. También protege contra el clickjacking: la directiva frame-ancestors impide que un sitio se incruste en iframes de dominios no autorizados, y limita los ataques de inyección de datos controlando qué imágenes, fuentes y contenido multimedia se permite cargar.
Como veremos, en la práctica esto no es del todo así.
El objetivo de CSP (cuando está correctamente configurada)
Defensa frente a contenido de terceros malicioso
Los sitios web suelen depender de contenido de terceros, como herramientas de analítica o scripts publicitarios, que pueden convertirse en vectores de ataque si se ven comprometidos. CSP minimiza este riesgo restringiendo el contenido a fuentes de confianza previamente aprobadas, protegiendo tu sitio frente a vulnerabilidades en bibliotecas de terceros.
Prevención de la exfiltración de datos
Los scripts maliciosos diseñados para extraer datos sensibles y enviarlos a dominios no autorizados son una amenaza constante. CSP actúa como barrera, bloqueando dichos scripts y garantizando que los datos de los usuarios permanezcan seguros.
Protección frente a ataques a la cadena de suministro
Combinada con la Integridad de Subrecursos (SRI), CSP valida los scripts y estilos de terceros para asegurarse de que no han sido alterados durante la entrega. Esto añade una salvaguarda teórica frente a compromisos en la cadena de suministro.
Control sobre comportamientos dinámicos no deseados
Las directivas CSP como script-src, style-src, y las restricciones sobre unsafe-eval impiden la ejecución de código generado o modificado dinámicamente. Esto reduce la superficie de ataque al limitar los exploits que dependen de eval() o de scripts en línea.
Ligera y altamente configurable
Entregada mediante cabeceras del lado del servidor, CSP tiene un impacto mínimo en el rendimiento de la aplicación. Su flexibilidad permite configuraciones a medida, lo que la hace adecuada para una amplia variedad de casos de uso y necesidades arquitectónicas.
Los desafíos y limitaciones de CSP
¿Por qué entonces CSP tiene tan mala fama? En teoría suena como una solución ideal. Una herramienta potente para controlar por completo qué puede cargar el navegador en un sitio web.
En la práctica, sin embargo, la realidad se queda muy lejos de esa promesa.
CSP es un mecanismo de defensa complementario, no una solución independiente, y conlleva desafíos y limitaciones significativos que pueden mermar su eficacia o incluso generar una falsa sensación de seguridad.
Complejidad de implementación
Elaborar una CSP eficaz para aplicaciones web modernas es una tarea difícil. Los sitios web suelen depender de numerosos dominios de terceros para analítica, CDN, publicidad y fuentes, lo que hace casi imposible crear una política estricta sin romper alguna funcionalidad. Gestionar directivas como script-src, style-src e img-src a través de fuentes diversas se vuelve, en efecto, inmanejable, especialmente en aplicaciones grandes y en constante evolución.
Incapacidad para bloquear scripts específicos
CSP opera con un modelo de lista de permitidos, que autoriza recursos de dominios de confianza pero no puede bloquear scripts o recursos individuales de esos dominios.
Un ejemplo rápido: si permites un dominio como cdn.example.com, CSP no puede impedir que se ejecuten scripts maliciosos alojados allí.
Las actualizaciones recientes de CSP introducen una función para abordar esta limitación mediante la Integridad de Subrecursos (SRI) integrada en la directiva script-src. Esto permite incluir en la lista de permitidos scripts específicos usando hashes de su contenido, garantizando que solo se cargue la versión exacta y verificada de un script.
Aunque potente en teoría, este enfoque tiene un inconveniente importante: cualquier actualización del script invalida el hash, lo que hace que la comprobación SRI falle y el script deje de funcionar.
Para scripts que se actualizan con frecuencia, como los de herramientas de marketing, esto hace que la función de hash sea inútil. A menos que trabajes con scripts garantizados como estáticos, este mecanismo es esencialmente inutilizable.
Elevado coste de mantenimiento
Las políticas CSP requieren actualizaciones frecuentes para adaptarse a:
- Nuevos scripts, estilos o recursos para funcionalidades o páginas añadidas.
- Cambios en dominios o servicios de terceros.
- Factores externos, como un cambio en una API de terceros, que pueden romper una política que hasta entonces funcionaba correctamente.
Solo para eso ya se necesita una herramienta de monitorización que detecte los cambios.
Riesgos derivados de dependencias de terceros
Permitir recursos de terceros en las políticas CSP implica confiar inherentemente en que esos dominios externos permanecerán seguros. Sin embargo, los scripts comprometidos o maliciosos de terceros de confianza pueden seguir ejecutándose, eludiendo por completo las protecciones de CSP.
Esta dependencia es en sí misma una vulnerabilidad crítica del modelo CSP.
Lo vimos en el ataque a Polyfill de 2024, donde ocurrió exactamente esto. Más de medio millón de sitios web confiaban en un único dominio para inyectar un script en su sitio. Incluso quienes contaban con una estrategia CSP robusta fueron víctimas.
Problemas con scripts y estilos en línea
Por defecto, CSP bloquea los scripts y estilos en línea, lo cual es una medida de seguridad razonable. Pero, de nuevo, hay problemas.
- Muchos frameworks (p. ej., React, Angular) y sistemas heredados dependen en gran medida de scripts en línea, lo que dificulta su aplicación sin una refactorización extensa.
- Muchas herramientas de marketing ofrecen ejemplos que usan etiquetas
<script>en línea para cargar paquetes de JavaScript externos. Aunque estos scripts podrían ejecutarse desde archivos separados, los ejemplos suelen incrustarlos directamente, complicando la aplicación de CSP e introduciendo riesgos potenciales. - Para adaptarse a esto, los desarrolladores suelen recurrir a unsafe-inline, lo que socava la seguridad de CSP al permitir todo el contenido en línea.
Uso excesivo de directivas permisivas
Para evitar romper la funcionalidad, los desarrolladores acaban debilitando las políticas CSP. Una forma contraproducente de priorizar la funcionalidad sobre la seguridad.
unsafe-inline: permite scripts y estilos en línea, anulando los objetivos de seguridad principales de CSP.unsafe-eval: permite el uso de eval() y métodos similares, altamente explotables.*(comodín): concede acceso a cualquier dominio, anulando de hecho el valor de la política.
Depuración de violaciones de CSP
Diagnosticar problemas relacionados con CSP es extremadamente lento y frustrante.
- Los navegadores registran las violaciones de CSP en la consola, pero los registros suelen carecer del contexto suficiente para identificar la causa raíz.
- Depurar políticas demasiado estrictas que rompen la funcionalidad requiere un esfuerzo considerable, lo que lleva a los desarrolladores a relajar la política y comprometer la seguridad.
Ruptura de funcionalidades existentes
Como se mencionó antes, las políticas CSP estrictas pueden interrumpir componentes esenciales.
- Integraciones de terceros como analítica, publicidad o widgets sociales.
- Aplicaciones heredadas que dependen de scripts en línea, estilos o recursos cargados dinámicamente. Para restaurar la funcionalidad, los desarrolladores suelen flexibilizar las restricciones, socavando la seguridad prevista.
Inconsistencias entre navegadores
La aplicación de CSP varía de un navegador a otro, lo que añade más problemas.
- Los navegadores más antiguos pueden ignorar por completo ciertas directivas.
- Algunas directivas, como worker-src o navigate-to, carecen de soporte universal, lo que limita su eficacia.
Falta de informes estandarizados
Aunque CSP admite informes de violaciones, no existe un formato ni una herramienta universalmente aceptados para procesarlos, lo que dificulta que los equipos los analicen y actúen sobre ellos de forma eficaz.
Métodos sencillos para eludir políticas CSP incompletas
Una de las mayores vulnerabilidades en configuraciones CSP incompletas es la ausencia de la directiva default-src. Sin ella, las políticas CSP pueden eludirse para exfiltrar datos mediante mecanismos como el prefetching.
Aunque default-src está pensada para establecer reglas de reserva, la especificación de CSP señala que el prefetching no está gobernado por su propia directiva, por lo que, sin default-src, los enlaces de prefetch eluden CSP por completo. Nuestro análisis de sitios web rastreados reveló un número sorprendente que carece de default-src, lo que los deja vulnerables a este exploit. Y connect-src tampoco ayuda: incluso un connect-src bien configurado no puede evitar la exfiltración basada en prefetch, ya que no se aplica a este tipo de conexiones.
Evita CSP, haz esto en su lugar
CSP tiene beneficios reales sobre el papel. Usarla en un entorno real se convierte rápidamente en una tarea engorrosa. Sin embargo, la seguridad del lado del cliente es cada vez más frecuente.
Al buscar una herramienta de seguridad del lado del cliente, asegúrate de comprobar que no dependa únicamente de CSP como base para la monitorización de recursos configurándola en modo "solo informe" (report-only). Sus soluciones dependen principalmente de CSP para rastrear e informar sobre el comportamiento de los recursos, ofreciendo capacidades de bloqueo limitadas como función adicional.
Aunque probablemente sea suficiente para el cumplimiento normativo, te deja expuesto a un mundo de problemas si sufres un ataque.
cside cuenta con soluciones de seguridad modernas que no dependen de CSP, para un enfoque más eficiente de la protección del lado del cliente. Hemos construido un servicio que hace un seguimiento de todos los scripts de tu sitio y que puede detectar y bloquear código malicioso de forma proactiva.
Sin necesidad de comprobaciones manuales ni de informes.
Puedes empezar gratis o contactarnos.
