En entornos web modernos, Content Security Policy (CSP) es una capa crítica de defensa para reducir el riesgo de ataques XSS (Cross-Site Scripting) al controlar las fuentes desde las que un navegador puede cargar recursos. Esta guía práctica ofrece pasos claros y recomendaciones para diseñar, implementar y verificar políticas CSP efectivas, complementadas por prácticas de monitoreo y pruebas automatizadas para mantener la seguridad a lo largo del ciclo de vida de la aplicación.
Implementación básica de CSP para XSS
La implementación básica de CSP comienza por definir una política que restrinja el origen permitido de scripts y otros recursos clave; esto se hace mediante el encabezado HTTP Content-Security-Policy o mediante la metaetiqueta en HTML. Para comprender las directivas principales y ejemplos de políticas, consulte la documentación técnica y ejemplos en el recurso de referencia de MDN Web Docs que explica la estructura y sintaxis de CSP.
Antes de desplegar una política agresiva en producción, es recomendable usar un enfoque iterativo: comenzar con una política relajada en modo monitorización y endurecerla progresivamente mientras se resuelven las incompatibilidades. La guía de OWASP sobre XSS y mitigaciones aporta contexto sobre cómo CSP reduce la superficie de ataque y qué escenarios de XSS pueden seguir siendo relevantes según las configuraciones, vea más en OWASP XSS.
Política de fuentes y evitando ‘unsafe-inline’
Una de las decisiones más importantes al diseñar CSP es evitar confiar en ‘unsafe-inline’ para scripts y estilos, ya que habilitarlo anula gran parte de la protección contra XSS permitiendo ejecución de código inline. En lugar de ello, adopte fuentes explícitas mediante hostnames, esquemas y tokens de confianza; la documentación en MDN sobre políticas de fuentes explica cómo usar claves como ‘self’, dominios y esquemas de manera segura.
Cuando no es posible eliminar todo código inline inmediatamente, utilice nonces o hashes para autorizar fragmentos concretos sin abrir la política a ‘unsafe-inline’; esto permite transitar hacia una política más segura mientras se corrigen dependencias y se refactoriza el código. Para estrategias de migración y ejemplos de hashes y nonces, consulte también las recomendaciones en OWASP.
Directivas CSP: script-src, style-src y nonce
Las directivas script-src y style-src controlan de forma directa los orígenes permitidos para la ejecución de JavaScript y la aplicación de estilos respectivamente, y deben configurarse con la menor permisividad compatible con la funcionalidad necesaria. Es habitual combinar fuentes seguras (por ejemplo ‘self’ y dominios específicos de CDN) con nonces o hashes para autorizar sólo elementos concretos, tal como se describe en la referencia técnica de MDN sobre script-src.
El uso de nonces (valores aleatorios por respuesta HTTP insertados en tags script/style) ofrece una alternativa práctica a los hashes cuando el contenido cambia frecuentemente; el servidor genera y embebe el nonce y la política lo valida en el navegador, lo que reduce la necesidad de inline-risk. Para la implementación correcta de nonces y ejemplos de uso, revise las especificaciones y guías de práctica en W3C Content Security Policy.
Reporte y monitoreo: CSP Report-Only y SRI
Antes de imponer una política restrictiva, utilice la directiva report-uri o el modo Report-Only para recopilar violaciones sin bloquear el contenido, permitiendo ajustar la política sin impacto inmediato en usuarios. El modo Report-Only y las opciones más modernas de reporting están bien explicadas en la documentación de MDN sobre Report-Only, incluyendo formatos de reporte y consideraciones de privacidad al almacenar logs.
Además, combine CSP con Subresource Integrity (SRI) para garantizar la integridad de recursos externos como scripts y hojas de estilo alojados en terceros; SRI añade un mecanismo criptográfico que complementa las restricciones de origen de CSP. Google y la documentación de web.dev sobre SRI ofrecen guías prácticas sobre cuándo y cómo aplicar hashes SRI en CDNs y librerías externas para reforzar la defensa.
Mejores prácticas y pruebas automatizadas CSP
Las mejores prácticas incluyen el principio de menor privilegio para origenes, la eliminación gradual de inline mediante nonces/hashes, el registro de violaciones y la revisión periódica de dependencias externas, todo alineado con políticas de despliegue automatizadas. Para verificar configuraciones y detectar puntos débiles automáticamente, aproveche herramientas como el CSP Evaluator de Google que analiza políticas y sugiere mejoras evitando configuraciones peligrosas.
Integrar pruebas CSP en pipelines CI/CD permite detectar regresiones y cambios en dependencias que podrían requerir ajustes de política; cree suites de pruebas que incluyan escenarios de carga de recursos y simulación de violaciones para asegurar estabilidad. También considere auditorías regulares y el uso de scanners y linters que tengan conocimiento de CSP, así como la consulta de recursos de referencia como la OWASP CSP Cheat Sheet para mantener un enfoque actualizado.
Implementar una política CSP bien diseñada es una inversión en la robustez de su seguridad web que, combinada con prácticas de codificación segura y pruebas continuas, reduce significativamente el riesgo de XSS. Planifique un despliegue gradual con monitorización y herramientas automáticas, y actualice las políticas conforme evoluciona la aplicación y su ecosistema de dependencias.