La Política de Seguridad de Contenido (CSP) es una función de seguridad que ofrecen los navegadores web y que los propietarios de sitios pueden 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:
Cross-Site Scripting (XSS): Al restringir las fuentes desde las que se pueden cargar scripts, CSP puede bloquar eficazmente los scripts maliciosos inyectados en una página web.
Por ejemplo, si una política CSP especifica script-src 'self', garantiza que solo se ejecuten scripts del propio dominio del sitio web.
Protección contra clickjacking: Mediante la directiva frame-ancestors, CSP impide que tu sitio sea incrustado en iframes en dominios no autorizados, reduciendo el riesgo de ataques de clickjacking.
Ataques de inyección de datos: CSP controla la carga de recursos como imágenes, fuentes y contenido multimedia, reduciendo los riesgos derivados de la inyección o manipulación de recursos.
Como veremos, en la práctica la realidad dista bastante de esto.
El objetivo de CSP (cuando está correctamente configurada)
Defensa contra 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 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 completamente 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 no es una solución independiente, sino un mecanismo de defensa complementario que conlleva desafíos y limitaciones significativos. Estas carencias 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 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 invalidará el hash, haciendo 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, lo que limita su aplicabilidad en el mundo real.
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 funcionaba correctamente.
Solo para esto 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 pone de manifiesto una vulnerabilidad crítica en el 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 aquellos 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 bundles 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 se ven obligados a debilitar las políticas CSP. Una forma contraproducente de priorizar la función 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, que son altamente explotables. - *******: Concede acceso a cualquier dominio, anulando efectivamente 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 ciertas directivas por completo.
- 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 vulnerabilidades clave en configuraciones CSP incompletas reside en la omisión de la directiva default-src. Sin esta directiva, las políticas CSP pueden eludirse para exfiltrar datos mediante mecanismos como la precarga (prefetching).
- El papel de default-src: Aunque está pensada para establecer reglas de reserva, la especificación CSP indica que el prefetching no está gobernado por su propia directiva. Sin default-src, los enlaces de prefetch eluden CSP por completo.
- Descuidos en el mundo real: Nuestro análisis de sitios web rastreados reveló que un número sorprendente carece de default-src, dejándolos vulnerables a este exploit.
- Connect-src no ayuda: Incluso un connect-src bien configurado no puede prevenir la exfiltración basada en prefetch, ya que no se aplica a ese tipo de conexiones.
Alternativas a CSP
CSP ofrece beneficios valiosos 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 relevante.
Al buscar una herramienta de seguridad del lado del cliente, asegúrate de comprobar que no dependa exclusivamente de CSP como base para la monitorización de recursos configurándola en modo "report-only". Estas 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 serios problemas si sufres un ataque.
cside ofrece soluciones de seguridad modernas que no dependen de CSP, proporcionando un enfoque más ágil y eficiente para la protección del lado del cliente. Hemos construido un servicio proxy que realiza un seguimiento de todos los scripts de tu sitio y puede detectar y bloquear código malicioso de forma proactiva.
Sin necesidad de comprobaciones manuales ni informes.
Puedes empezar gratis o contactarnos.
