CSP y HSTS sin romper tu web: guía práctica con ejemplos y checklist

¿Por qué son importantes CSP y HSTS?

CSP y HSTS son dos poderosas herramientas de seguridad web que trabajan en conjunto para proteger tu sitio y la información de tus usuarios. CSP (Content Security Policy) te ayuda a prevenir ataques de cross-site scripting (XSS) al controlar las fuentes de contenido que tu navegador web puede cargar. HSTS (HTTP Strict Transport Security) obliga a los navegadores a usar conexiones HTTPS, protegiendo a tus usuarios de ataques man-in-the-middle y garantizando una comunicación segura.

Implementar estas políticas de seguridad puede parecer complejo, pero con un enfoque metódico y precauciones, puedes mejorar significativamente la seguridad de tu sitio sin afectar su funcionalidad.

Paso a paso: Configurando CSP y HSTS sin riesgos

La clave para una configuración exitosa de CSP y HSTS es un enfoque gradual y una cuidadosa verificación de cada paso. Aquí te presentamos una guía detallada:

Paso 1: Identifica los recursos de tu sitio web

Antes de empezar a configurar CSP, necesitas saber qué recursos carga tu sitio. Utiliza las herramientas de desarrollo de tu navegador (Chrome, Firefox, etc.) para inspeccionar los scripts, estilos, imágenes y otros recursos que se están cargando. Presta atención a las fuentes externas, como CDN (Content Delivery Networks) o APIs, ya que necesitarás incluirlas en tu política CSP.

Paso 2: Implementa CSP en modo "Report-Only"

Este es el paso más crucial para evitar "romper" tu sitio. En lugar de activar la política CSP de inmediato, configúrala en modo "report-only". Esto significa que el navegador informará sobre las violaciones de la política, pero no bloqueará los recursos. Esto te permite identificar qué recursos están infringiendo tu política sin afectar la funcionalidad de tu sitio. Puedes configurar esto agregando el header Content-Security-Policy-Report-Only a tus respuestas HTTP.

Ejemplo:

      Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://cdn.ejemplo.com; report-uri /report-csp
    

En este ejemplo:

• default-src 'self': Permite la carga de recursos desde el mismo origen del sitio.
• script-src 'self' https://cdn.ejemplo.com: Permite la carga de scripts desde el mismo origen y desde la CDN cdn.ejemplo.com.
• report-uri /report-csp: Especifica la URL a la que se enviarán los informes de las violaciones de la política. Debes configurar un endpoint en tu servidor para recibir y analizar estos informes.

Paso 3: Analiza los informes de CSP

Una vez que hayas implementado CSP en modo "report-only", debes analizar los informes que recibes. Estos informes te indicarán qué recursos están violando tu política y por qué. Presta atención a los errores y ajusta tu política CSP en consecuencia. Puedes usar herramientas de análisis de logs o crear tu propio script para procesar los informes CSP. Presta especial atención a:

• Scripts en línea (inline scripts): Los scripts definidos directamente en el HTML suelen ser una fuente común de problemas. Considera usar nonces o hashes para autorizarlos (ver paso 5).
• Fuentes no autorizadas: Asegúrate de incluir todas las fuentes necesarias en tu política.

Paso 4: Refina tu política CSP

Basándote en el análisis de los informes, refina tu política CSP. Ajusta las directivas script-src, img-src, style-src, connect-src y otras según sea necesario. Asegúrate de incluir todas las fuentes necesarias y de evitar el uso de comodines (*) en la medida de lo posible, ya que esto reduce la efectividad de CSP.

Ejemplo:

      Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-R4nd0mN0nc3' https://cdn.ejemplo.com; style-src 'self' https://fonts.googleapis.com; img-src 'self' data:; connect-src 'self' https://api.ejemplo.com
    

En este ejemplo, se incluyen:

• 'nonce-R4nd0mN0nc3': Un nonce para autorizar un script inline. El nonce debe ser generado de forma aleatoria en cada solicitud y coincidir con el atributo nonce del script en el HTML.
• https://fonts.googleapis.com: Permite la carga de fuentes desde Google Fonts.
• data:: Permite la carga de imágenes en formato base64 (data URIs).
• https://api.ejemplo.com: Permite la conexión a la API de tu sitio web.

Paso 5: Consideraciones sobre scripts en línea (inline scripts)

Los scripts en línea (aquellos definidos directamente dentro del código HTML) pueden ser un desafío para CSP. Existen varias opciones para manejarlos:

• Nonces: Genera un nonce único para cada solicitud y agrégalo al atributo nonce del script y a la directiva script-src de CSP. Esta es la opción más segura.
• Hashes: Calcula el hash (SHA-256, SHA-384 o SHA-512) del contenido del script y agrégalo a la directiva script-src de CSP. Esta opción es útil para scripts pequeños y estáticos.
• Evitar: La mejor práctica es evitar los scripts en línea siempre que sea posible. Traslada el código a archivos externos y haz referencia a ellos.
• Evita 'unsafe-inline': Nunca uses 'unsafe-inline' en producción, ya que deshabilita la protección de CSP contra XSS.

Paso 6: Implementa HSTS

Una vez que estés seguro de que tu sitio web funciona correctamente con HTTPS, puedes implementar HSTS. HSTS le indica al navegador que siempre use HTTPS para comunicarse con tu sitio.

Empieza con un max-age corto (por ejemplo, 30 días) para permitir la reversión en caso de problemas. Luego, aumenta gradualmente el max-age y, finalmente, considera agregar includeSubDomains y preload.

Ejemplo:

      Strict-Transport-Security: max-age=2592000; includeSubDomains; preload
    

En este ejemplo:

• max-age=2592000: Indica al navegador que recuerde que el sitio debe ser accedido solo a través de HTTPS durante 2592000 segundos (30 días).
• includeSubDomains: Aplica HSTS a todos los subdominios del sitio. Úsalo solo si todos los subdominios soportan HTTPS.
• preload: Indica al navegador que precarque el sitio web en la lista de precarga de HSTS de los navegadores. Esto mejora aún más la seguridad, pero es difícil de revertir. Antes de usar preload, verifica los requisitos en hstspreload.org.

Paso 7: Despliegue y monitoreo continuo

Una vez que hayas configurado CSP y HSTS, despliega los cambios en producción. Continúa monitoreando los informes CSP y los errores del sitio web para detectar cualquier problema. Ajusta las políticas según sea necesario y mantén un ojo en las actualizaciones de seguridad. Recuerda que la seguridad web es un proceso continuo.

Checklist Accionable para la Configuración de CSP y HSTS

Utiliza esta checklist para asegurarte de que has cubierto todos los pasos necesarios:

• [ ] Paso 1: Identifica todos los recursos que carga tu sitio web (scripts, estilos, imágenes, fuentes, APIs, etc.).
• [ ] Paso 2: Implementa CSP en modo "Report-Only" (Content-Security-Policy-Report-Only).
• [ ] Paso 3: Configura un endpoint para recibir y analizar los informes CSP (report-uri).
• [ ] Paso 4: Analiza los informes CSP y ajusta la política para incluir todas las fuentes necesarias.
• [ ] Paso 5: Implementa nonces o hashes para scripts en línea (evita 'unsafe-inline').
• [ ] Paso 6: Implementa HSTS con un max-age corto.
• [ ] Paso 7: Aumenta gradualmente el max-age de HSTS.
• [ ] Paso 8: Considera agregar includeSubDomains y preload (si es apropiado).
• [ ] Paso 9: Despliega los cambios en producción y monitorea continuamente los informes CSP y los errores del sitio web.

Errores comunes y soluciones

Evitar los errores comunes es esencial para una implementación exitosa de CSP y HSTS. Aquí están algunos de los errores más comunes y cómo solucionarlos:

• Error: Activar includeSubDomains en HSTS cuando tienes subdominios que no soportan HTTPS.
  • Solución: Asegúrate de que todos tus subdominios también utilicen HTTPS antes de activar includeSubDomains. De lo contrario, los usuarios no podrán acceder a esos subdominios.
• Error: Usar * en la directiva script-src de CSP.
  • Solución: Esto deshabilita la protección XSS. En lugar de *, especifica las fuentes de script permitidas ('self', CDN, etc.) o usa nonces/hashes.
• Error: No configurar o no monitorizar el endpoint de informes CSP (report-uri).
  • Solución: Debes configurar un endpoint para recibir y analizar los informes CSP. Si no lo haces, perderás visibilidad de las violaciones de la política y no podrás corregirlas.
• Error: Implementar dos políticas CSP que entran en conflicto (por ejemplo, una en el código de la aplicación y otra en un CDN).
  • Solución: Fusiona las políticas en una sola o asegúrate de que las políticas no entren en conflicto. La política más restrictiva tendrá prioridad.
• Error: Olvidar el header Vary: Origin al configurar CORS dinámico, que puede llevar a vulnerabilidades de seguridad.
  • Solución: Asegúrate de incluir el header Vary: Origin cuando configures CORS dinámico. Esto asegura que las respuestas varíen según el origen de la solicitud, previniendo posibles ataques.

Preguntas frecuentes (FAQ)

Recomendación final según el perfil o caso de uso

La configuración de CSP y HSTS debe adaptarse a las necesidades específicas de tu sitio web y al nivel de riesgo que estás dispuesto a aceptar. Aquí te presentamos algunas recomendaciones:

• Para sitios web pequeños y estáticos: Comienza con una política CSP simple que permita la carga de recursos desde el mismo origen ('self') y desde CDN confiables. Implementa HSTS con un max-age moderado.
• Para aplicaciones web complejas: Implementa CSP de manera más estricta, utilizando nonces o hashes para scripts en línea y limitando las fuentes de recursos. Usa HSTS con includeSubDomains y, si es posible, preload, después de una cuidadosa consideración.
• Para sitios web de comercio electrónico o que manejan información sensible: Prioriza la seguridad. Implementa CSP y HSTS de forma muy estricta, revisando y actualizando regularmente las políticas. Considera el uso de mecanismos adicionales de seguridad, como la autenticación de dos factores.
• Para desarrolladores que trabajan con marcos de trabajo modernos (React, Angular, Vue): Estos marcos a menudo requieren una gestión cuidadosa de CSP debido a la forma en que cargan y ejecutan scripts. Es crucial revisar la documentación específica del marco y usar las mejores prácticas para integrar CSP de forma segura.

Recuerda que la seguridad web es un proceso continuo. Mantente al día con las últimas amenazas y vulnerabilidades, y actualiza tus políticas de seguridad en consecuencia.