CSP - Política de seguridad de contenido
Lectura de 2 min aprox.
CSP (Content Security Policy) es un mecanismo de seguridad que declara, mediante una cabecera de respuesta HTTP, el origen permitido de los recursos que pueden ejecutarse en una página web. Se estandarizó en el W3C en 2012 como una capa defensiva que reduce considerablemente el daño del cross-site scripting (XSS). Al hacer que el servidor indique al navegador que «en esta página solo pueden ejecutarse scripts de este dominio», bloquea a nivel del navegador la ejecución de scripts maliciosos inyectados por un atacante.
Su papel como medida contra el XSS
Lo fundamental para prevenir el XSS es la sanitización de la entrada y el escape de la salida, pero estas medidas son propensas a fallos por errores del desarrollador. La CSP funciona como una «última línea de defensa» que complementa estas medidas. Aunque un descuido en el escape permita que código de ataque se cuele en el HTML, una CSP bien configurada hace que el navegador se niegue a ejecutar ese script. Combinar la codificación segura con la CSP logra una defensa en profundidad.
Directivas principales
| Directiva | Controla | Ejemplo |
|---|---|---|
| default-src | Reserva para otras directivas | 'self' |
| script-src | Carga y ejecución de JavaScript | 'self' 'nonce-abc123' |
| style-src | Carga y aplicación de CSS | 'self' 'unsafe-inline' |
| img-src | Orígenes desde los que cargan las imágenes | 'self' data: https://cdn.example.com |
| connect-src | Destinos de fetch / XHR / WebSocket | 'self' https://api.example.com |
| frame-ancestors | Orígenes autorizados a incrustar en un iframe | 'none' |
| form-action | Destinos de envío de formularios | 'self' |
Métodos de autorización basados en nonce y en hash
Existen dos formas de permitir scripts en línea: el método nonce y el método hash.
El servidor genera un valor aleatorio (nonce) para cada solicitud e incrusta el mismo valor tanto en la cabecera CSP como en la etiqueta script. Solo se ejecutan los scripts cuyos valores coinciden. Es adecuado para páginas dinámicas, y marcos de trabajo como Next.js y Rails admiten la generación automática del nonce.
Se calcula un valor hash como SHA-256 a partir del contenido del script en línea y se incluye en la cabecera CSP. Si cambia aunque sea un byte del contenido del script, el hash no coincidirá y no se ejecutará. Es adecuado para scripts estáticos, pero hay que recalcular el hash cada vez que cambia el contenido.
Monitoreo con report-uri / report-to
La CSP incluye un mecanismo para reportar las violaciones de la política al servidor. report-uri (especificación antigua) o report-to (especificación nueva) le permiten indicar el destino del informe; después, el navegador envía un informe en formato JSON cada vez que detecta una violación de la política. Primero, recopile solo informes con la cabecera Content-Security-Policy-Report-Only y confirme que no se rompe ninguna funcionalidad existente antes de pasar a la aplicación en producción; este es el procedimiento de implementación seguro.
El flujo de implementación de la CSP
Errores comunes al implementar
Añadir 'unsafe-inline' solo porque los scripts en línea no funcionan anula casi por completo la protección XSS de la CSP. Migrar al método nonce es la respuesta correcta.
Especificar * en script-src permite cargar scripts desde cualquier dominio. Enumere individualmente los dominios autorizados.
Olvidar scripts de terceros como anuncios, analíticas y widgets de chat hará que las funciones dejen de funcionar en producción.
La CSP es una tecnología fundamental de seguridad web junto con WAF y SSL/TLS. libros sobre seguridad web (Amazon) son recomendables para un aprendizaje sistemático. Consulte también la seguridad de las extensiones del navegador, la seguridad de las contraseñas del navegador y la lista de verificación de seguridad para startups.
¿Te resultó útil este artículo?