CSP

CSP (Content Security Policy) es una cabecera de respuesta HTTP que indica a los navegadores qué fuentes de contenido confía la página. Define listas blancas por tipo de contenido: script-src para JavaScript, style-src para CSS, img-src para imágenes, connect-src para fetch/XHR/WebSocket, frame-src para iframes, etc.

Ejemplo de cabecera: Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:.

El valor principal de CSP: defensa en profundidad contra XSS. Incluso si un atacante inyecta JavaScript en su página, una CSP estricta impide que el navegador lo ejecute (porque se carga desde un origen que no está en la lista blanca) o envíe datos a ningún lugar (porque connect-src bloquea la exfiltración hacia dominios del atacante).

La mejor práctica moderna: usar una CSP basada en nonce — cada respuesta de página incluye un nonce aleatorio en su cabecera CSP (p. ej., script-src 'nonce-AbC123') y las etiquetas de script en línea que coincidan con ese nonce pueden ejecutarse. Esto es estricto pero permite distribuir contenido dinámico de forma segura. Los analizadores estáticos como el Evaluador de CSP de Google puntúan su política e identifican debilidades.

Errores comunes de CSP que anulan el propósito: usar 'unsafe-inline' en script-src (vuelve a permitir la inyección en línea que se intentaba bloquear), usar comodines https: como fuente de script (cualquier host HTTPS puede ahora servir JS a su origen), o confiar en un host CDN compatible con JSONP que permite a los atacantes crear una URL que devuelve JavaScript controlado por el atacante. El artículo de 2016 “CSP Is Dead, Long Live CSP!” del equipo de seguridad de Google mostró que el 95% de las políticas en uso eran fácilmente eludibles por exactamente estas razones; 'strict-dynamic' + nonces fue su solución propuesta y es ahora la recomendación predeterminada.

CSP reporta las violaciones de política a una URL especificada en report-uri (obsoleto) o report-to. Despliegue primero una nueva política en modo Content-Security-Policy-Report-Only — el navegador reportará las violaciones sin bloquear el contenido, permitiéndole corregir fuentes legítimas antes de la aplicación. Relacionado: XSS, CORS, SRI (Integridad de subrecursos). Referencia: W3C CSP Nivel 3.

Un ejemplo medido: cómo funciona strict-dynamic

Una política estricta del mundo real se ve así: Content-Security-Policy: script-src 'nonce-r4nd0m' 'strict-dynamic' https:; object-src 'none'; base-uri 'none'. El servidor genera un nonce fresco de 128 bits por respuesta (típicamente 22 caracteres base64url), lo incrusta en etiquetas <script nonce="r4nd0m"> correspondientes y emite la cabecera. strict-dynamic propaga la confianza transitivamente: los scripts cargados por el script con nonce pueden a su vez cargar más scripts sin listas blancas explícitas, pero los scripts inyectados sin nonce en el código fuente de la página están bloqueados. El Evaluador de CSP de Google puntúa las políticas en una escala de 0 a 10; una política strict-dynamic sin 'unsafe-inline' y sin comodines de host puntúa 9+, mientras que una política heredada típica con fuentes CDN con comodines puntúa 1-3. El mismo estudio de Google que cubrió 1,6 millones de políticas en el millón de Alexa encontró que añadir strict-dynamic redujo la proporción eludible por XSS del 95% a menos del 5%.

Cómo CSP interactúa con las características del navegador

CSP bloquea más que solo la ejecución de scripts. connect-src restringe fetch, XHR, WebSocket, EventSource y la Beacon API — útil para detener la exfiltración de datos incluso después de un XSS exitoso. frame-ancestors reemplaza la cabecera X-Frame-Options más antigua para la protección contra clickjacking. upgrade-insecure-requests reescribe automáticamente las URLs de subrecursos HTTP a HTTPS. require-trusted-types-for 'script' incorpora la página a la API Trusted Types, que obliga a todos los sumideros DOM (innerHTML, eval, etc.) a aceptar solo objetos con tipos especiales, bloqueando XSS basado en DOM en la fuente. Los navegadores modernos envían informes de violaciones como JSON al endpoint report-to, agrupados mediante la API de Reporting. Referencia: Artículo ACM CCS 2016 de Google “CSP Is Dead, Long Live CSP!”.