CSP (Content Security Policy)

Qué es CSP (Content Security Policy)

CSP (Content Security Policy) es un encabezado de respuesta HTTP que permite al servidor controlar las fuentes de los recursos (scripts, hojas de estilo, imágenes, fuentes, etc.) que una página web puede cargar. El navegador bloquea la carga o ejecución de recursos no permitidos por CSP, lo que reduce significativamente el daño de los ataques XSS (Cross-Site Scripting).

La medida fundamental contra XSS es el escape de salida, pero las omisiones de implementación no se pueden eliminar por completo. CSP cumple el rol de defensa multicapa de "no permitir la ejecución del script del atacante incluso si existe una vulnerabilidad XSS". Es uno de los encabezados de seguridad más potentes y complejos.

Directivas principales

CSP se compone de múltiples directivas que especifican las fuentes permitidas para cada tipo de recurso.

• default-src: Política predeterminada para recursos no especificados explícitamente por otras directivas. default-src 'self' permite solo recursos del mismo origen.
• script-src: Controla las fuentes de carga de JavaScript. La directiva central para la protección contra XSS. Se recomienda evitar 'unsafe-inline' y usar nonce o hash.
• style-src: Controla las fuentes de carga de CSS.
• img-src: Controla las fuentes de carga de imágenes.
• connect-src: Controla los destinos de conexión de fetch, XMLHttpRequest y WebSocket.
• font-src: Controla las fuentes de carga de fuentes web.
• frame-src: Controla las fuentes de incrustación de iframe. También relacionado con la protección contra clickjacking.
• frame-ancestors: Controla los orígenes de las páginas padre que pueden incrustar el sitio en iframe. Sucesor de X-Frame-Options.

Métodos de especificación de valores de fuente

• 'self': Mismo origen
• 'none': Bloquear todo
• 'nonce-{random}': Permitir solo scripts/estilos inline con un valor nonce específico
• 'strict-dynamic': Permitir también los scripts cargados dinámicamente por scripts autorizados con nonce
• Dominios específicos: https://cdn.example.com

Pasos para una implementación gradual

La implementación de CSP debe realizarse gradualmente para no romper el sitio existente.

Paso 1: Monitoreo en modo Report-Only

Usando el encabezado Content-Security-Policy-Report-Only, solo se detectan y reportan las violaciones de política sin bloquear recursos. Primero, en este modo, se comprende qué recursos carga actualmente el sitio.

Paso 2: Elaboración de la política básica

Basándose en el análisis de los reportes, se agregan las fuentes de recursos necesarias a la lista blanca. Se comienza con una política permisiva y se va haciendo más estricta gradualmente.

Paso 3: Aplicación en producción y monitoreo continuo

Se cambia al encabezado Content-Security-Policy para la aplicación en producción. Se recopilan continuamente reportes de violaciones de política con las directivas report-uri o report-to para responder a falsos positivos y nuevos requisitos de recursos.

Ejemplo de política estricta recomendada

default-src 'none'; script-src 'self' 'nonce-{random}' 'strict-dynamic'; style-src 'self' 'nonce-{random}'; img-src 'self' data:; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

Esta política controla los scripts inline con nonce y permite también los scripts cargados dinámicamente con 'strict-dynamic'.

Integración de CSP con otros encabezados de seguridad

CSP es potente por sí solo, pero combinándolo con otros encabezados de seguridad se puede construir una defensa más robusta.

• Combinación con HSTS: Forzar HTTPS y prevenir la alteración de los encabezados CSP mediante ataques de intermediario. HTTPS es un requisito previo para maximizar la efectividad de CSP.
• X-Content-Type-Options: nosniff: Prevenir el MIME type sniffing y bloquear la ejecución de recursos que no deberían interpretarse como scripts.
• Relación con CORS: CSP controla las fuentes de carga de recursos y CORS controla los derechos de acceso de solicitudes cross-origin. Ambos tienen una relación complementaria.

La implementación de CSP tiene un costo inicial, pero aumenta drásticamente la capacidad de defensa contra XSS y clickjacking. En proyectos nuevos, incorporar CSP en el diseño desde las primeras etapas de desarrollo reduce significativamente el costo en comparación con una implementación posterior.

Conceptos erróneos comunes

Si se configura CSP, las medidas contra XSS son innecesarias

CSP es una capa de defensa multicapa que mitiga el daño de XSS, no sustituye la medida fundamental contra XSS (escape de salida). También se investigan técnicas para evadir CSP, por lo que se recomienda implementar tanto escape de salida como CSP.

CSP es difícil de configurar, así que no es necesario para sitios pequeños

El riesgo de XSS existe incluso en sitios pequeños. Comenzar con una política mínima (ejemplo: default-src 'self'; script-src 'self') facilita la implementación. Se puede verificar el impacto con el modo Report-Only y hacer más estricta la política gradualmente.

Términos relacionados

Artículos relacionados