La seguridad de las aplicaciones web es un desafío constante para cualquier organización que maneje datos críticos. Uno de los vectores de ataque más recurrentes es la inyección de scripts maliciosos (XSS), que puede comprometer sesiones de usuario, robar información sensible o redirigir a sitios fraudulentos. Para mitigar este riesgo, una de las herramientas más eficaces es la Política de Seguridad de Contenido (CSP), en particular la directiva script-src. En este artículo exploraremos cómo controlar los scripts permitidos en una página mediante hashes, nonces y strict-dynamic, ofreciendo una visión práctica y profesional para desarrolladores y responsables de seguridad.
Antes de profundizar, conviene entender el contexto. CSP actúa como una capa adicional de defensa que le dice al navegador cuáles son los orígenes y contenidos de scripts que la aplicación ha autorizado explícitamente. La directiva script-src abarca tanto scripts externos (cargados desde una URL) como scripts inline y manejadores de eventos en atributos HTML. Sin una política adecuada, cualquier script inyectado por un atacante podría ejecutarse. Por eso, en entornos donde desarrollamos aplicaciones a medida, la implementación de CSP se convierte en un requisito indispensable para garantizar la ciberseguridad del producto final.
El enfoque más sencillo es usar listas blancas de orígenes (script-src 'self' https://cdn.ejemplo.com). Sin embargo, esta solución tiene limitaciones importantes. Si permitimos un origen completo, estamos confiando en todos los ficheros servidos desde allí, incluidos aquellos que podrían ser comprometidos. Aunque podemos restringir a rutas específicas, en la práctica muchos CDN y servicios de terceros exigen un acceso amplio. Además, las listas blancas no autorizan scripts inline; para ello necesitamos hashes o nonces. En nuestro trabajo con clientes que migran a servicios cloud AWS y Azure, hemos visto cómo una política mal configurada puede bloquear funcionalidades legítimas o abrir brechas de seguridad.
Los hashes son huellas criptográficas del contenido exacto de un script inline. Funcionan bien cuando el script es estático, como una versión de la aplicación generada en tiempo de compilación. El navegador calcula el hash y lo compara con el que aparece en la cabecera CSP. Si coinciden, se ejecuta. Este método es robusto, pero falla cuando el script cambia por usuario o por petición, por ejemplo, al incluir un identificador de sesión o una configuración personalizada. Además, cualquier variación mínima (espacios, saltos de línea) invalida el hash. Por eso, en escenarios donde el contenido es dinámico, los nonces resultan más apropiados.
Un nonce es un token aleatorio que el servidor genera para cada respuesta HTTP. Se inserta tanto en la cabecera CSP como en el atributo nonce de la etiqueta <script>. El navegador verifica que coincidan, sin importar el contenido del script. Esto permite inyectar datos variables sin necesidad de recalcular hashes. La condición es que el nonce sea criptográficamente aleatorio y único por petición; de lo contrario, un atacante podría predecirlo y saltarse la protección. Los nonces son ideales para aplicaciones que generan HTML fresco en cada petición (como las que integran inteligencia artificial o agentes IA para personalizar la experiencia de usuario). No obstante, no sirven para páginas cacheadas o sitios estáticos, porque el nonce se repetiría, perdiendo su valor. En esos casos, los hashes son la mejor alternativa.
Cuando un script autorizado necesita cargar otros scripts dinámicamente (por ejemplo, un SDK de análisis o un widget de chat), surge un problema: el script hijo no tiene nonce ni hash. La directiva strict-dynamic resuelve esto propagando la confianza desde el script original a todos los que este cargue mediante document.createElement('script'). De esta forma, evitamos tener que listar cada origen de terceros, reduciendo la superficie de ataque. Eso sí, el script original debe estar autorizado mediante nonce o hash. Es crucial auditar ese script, ya que si es vulnerable o está comprometido, puede ejecutar código malicioso. En Q2BSTUDIO, al desarrollar software a medida, aplicamos strict-dynamic para integrar librerías externas minimizando riesgos, siempre combinado con un riguroso pentesting para detectar posibles puntos de fuga.
Otro aspecto a considerar son los manejadores de eventos inline como onclick o onload. Estos también están controlados por script-src. Si usamos nonces o hashes, no podemos aplicarlos directamente a esos atributos. La solución es migrar la lógica a bloques <script> con addEventListener, o bien separar las reglas mediante script-src-elem (para etiquetas script) y script-src-attr (para manejadores). Esta separación permite adoptar CSP de forma gradual, sin tener que elegir entre unsafe-inline o bloquear todo. En proyectos de servicios inteligencia de negocio que utilizan Power BI, por ejemplo, se suelen incluir scripts de integración; segmentar las directivas ayuda a mantener la seguridad sin romper la funcionalidad.
Finalmente, recordemos que CSP no es una solución mágica. No protege contra vulnerabilidades internas como open redirects, donde un script confiable redirige a un sitio malicioso basándose en parámetros de URL. La seguridad debe abordarse en múltiples capas: validación de entradas, saneamiento de salidas, y políticas CSP bien diseñadas. En Q2BSTUDIO ofrecemos servicios de ciberseguridad y asesoría en implementación de CSP, ayudando a empresas a proteger sus aplicaciones web mientras aprovechan tecnologías como ia para empresas y agentes IA de forma segura. Además, integramos estas prácticas en nuestros procesos de automatización de procesos para garantizar que la seguridad acompañe a la eficiencia.
En resumen, el control de scripts con CSP es una disciplina que requiere entender cuándo usar cada técnica: hashes para contenido estático, nonces para contenido dinámico por sesión, y strict-dynamic para cargas dinámicas de terceros. La elección depende de la arquitectura de la aplicación y del modelo de despliegue. Implementar una política robusta no solo previene ataques XSS, sino que también genera confianza en los usuarios y cumple con estándares de cumplimiento normativo. Si deseas fortalecer la seguridad de tus aplicaciones o necesitas orientación en la adopción de estas prácticas, en Q2BSTUDIO contamos con un equipo experto en desarrollo, cloud y ciberseguridad listo para acompañarte.
