Resumen
- El JavaScript de terceros está en todas partes (mediana: 22 scripts por página) y se ejecuta con los mismos privilegios que tu propio código.
- Si un proveedor se ve comprometido, tu sitio web también lo está: los scripts maliciosos pueden acceder a datos de usuarios, campos de formulario, cookies y tokens de sesión.
- Las mejores prácticas para la seguridad de scripts de terceros incluyen: un inventario de scripts en tiempo real + acceso de mínimo privilegio + verificaciones de integridad con detección de cambios y alertas + monitorización continua en tiempo de ejecución.
- Algunas de estas prácticas pueden implementarse con controles del navegador como CSP o monitorización manual, pero la protección real y el cumplimiento de marcos como GDPR y PCI DSS dependen de una herramienta especializada como cside.
Mejores prácticas para proteger scripts de terceros en páginas web
Según el Web Almanac 2024 de HTTP Archive, el 92% de las páginas web utilizan recursos de terceros. Los archivos JavaScript son el tipo de recurso de terceros más común, con aproximadamente el 30% de las solicitudes a terceros. En 2024, la página móvil mediana realizó 22 solicitudes de JavaScript por página. En el percentil 90, ese número ascendió a 68. En escritorio, las cifras son similares: 23 y 70 respectivamente.
Una vez permitidos, los scripts se ejecutan libremente. Cuando un proveedor se ve comprometido o se manipula una CDN, el código malicioso puede colarse en el navegador de los usuarios. En este artículo analizamos las mejores prácticas para la seguridad de JavaScript de terceros sin sacrificar velocidad ni funcionalidad.
1. Inventario completo de scripts y visibilidad
Un "inventario" en tiempo real de cada script servido a los usuarios en el navegador es un buen punto de partida. El inventario debe registrar desde dónde se carga el código: ¿un proveedor o biblioteca de terceros que elegiste, o algún cuarto partido desconocido?
sin inventario = sin visibilidad = sin control
Las páginas de pago son especialmente de alto riesgo. En un mundo ideal, no habría scripts de terceros en las páginas de pago. Riesgo cero. Pero eso no va a ocurrir. Los procesadores de pago y otras herramientas de checkout requieren JavaScript para el flujo de pago.
Una plataforma de protección del lado del cliente como cside elimina el trabajo manual generando y manteniendo automáticamente un inventario de scripts en tiempo real.
2. Acceso de mínimo privilegio para scripts
Para cada script, verifica a qué datos accede y pregúntate: ¿por qué? Presta especial atención a los scripts que acceden a datos sensibles como campos de formulario, cookies o tokens de sesión. No todos los scripts necesitan privilegios completos, pero sin controles en vigor los scripts tienen un camino directo para extraer información sensible.
¿Por qué necesitaría un script de analítica acceder a datos de pago? Los píxeles de marketing no tienen ningún motivo para leer nombres de usuario y contraseñas, ¿verdad?
CSP para restringir qué scripts se cargan
Por defecto, los navegadores ejecutarán cualquier script, incluidos los scripts encadenados. Restringir el acceso a los datos es fundamental para tu defensa. Una Content Security Policy (CSP) define desde dónde puede cargarse el código: por ejemplo, solo tus propios servidores y fuentes de terceros en lista blanca. Estableces esas reglas en tus cabeceras HTTP o en el HTML, y el navegador las aplica.
CSP solo comprueba desde dónde se carga el código, pero no qué hace una vez que está en ejecución. El código es dinámico y se actualiza. Si código malicioso se carga desde una fuente de confianza, tu CSP no lo bloqueará.
CSP es un punto de partida, pero está lejos de ser una defensa completa. Las CSP se basan enteramente en el dominio de origen desde el que se carga un script, y no analizan el comportamiento de los scripts.
Con cside puedes configurar políticas que restrinjan el acceso de los scripts según su comportamiento. Es decir, se puede permitir que determinados scripts lean cookies o entradas de formulario, mientras que todos los demás scripts (incluidos los aprobados) quedan bloqueados para ejecutar acciones de navegador de riesgo.
3. Verificar la integridad, detectar cambios y configurar alertas
Tu mecanismo de seguimiento también debe vigilar los cambios y actualizaciones de los scripts. Un script puede estar sano y seguro un día, y ver su integridad comprometida con una actualización.
Un control nativo del navegador para esto es Subresource Integrity (SRI). SRI añade un hash criptográfico a los scripts o etiquetas <link>. Actúa como garantía de la integridad del código. Cuando el navegador carga un script, comprueba el hash. Si un solo byte es diferente, el navegador no ejecutará el código. SRI funciona bien para proteger activos estáticos de terceros y detecta modificaciones a nivel de CDN. Sin embargo, SRI falla con los scripts dinámicos, de los que depende la mayoría de los sitios web modernos.
Una solución de proveedor (como cside) puede utilizarse para monitorizar la integridad de los scripts a través de varias capas de un motor de detección. Los equipos de seguridad reciben alertas automáticas cuando se produce una anomalía de comportamiento o un compromiso conocido de un proveedor en la cadena de suministro.
4. Usar monitorización en tiempo de ejecución que analice el comportamiento de los scripts
Los "escáneres remotos" son fáciles de implementar, pero tienen visibilidad limitada. Una investigación de ISACA concluye que estas herramientas de pruebas de seguridad pasan por alto amenazas en las que el código se carga de forma condicional para evitar dichos análisis. Las soluciones de tipo "escáner" también se limitan a la detección, con escasa capacidad para bloquear código malicioso.
Revisar el código de terceros antes de desplegarlo en producción también tiene sus limitaciones. Muchos scripts se aprueban una vez, rara vez se revisan, pero cambian con frecuencia. Un script puede superar la revisión antes de publicarse y, meses después, contener código malicioso.
La monitorización en tiempo de ejecución detecta scripts comprometidos procedentes de fuentes de confianza. Cuando un script comienza de repente a leer campos de formulario o a realizar solicitudes de red, consúltalo en tu inventario y bloquéalo. La monitorización en tiempo de ejecución observa los scripts en acción. Incluso aspectos como la manipulación del DOM pueden rastrearse con monitorización en tiempo de ejecución.
Llevar esto a cabo con herramientas desarrolladas internamente se vuelve rápidamente inviable. Acabas creando tu propio antivirus e invirtiendo recursos considerables en un proyecto que no está alineado con tu negocio principal. Existen numerosas soluciones listas para usar, como cside, que ejecutan la monitorización en tiempo de ejecución automáticamente en tus páginas y organizan los datos en paneles de control y alertas claros.
5. Alineación con el cumplimiento normativo
El cumplimiento normativo tiene fama de generar papeleo interminable. Los controles del lado del cliente son requeridos por un número creciente de marcos normativos, incluidos GDPR, PCI DSS y CCPA/CPRA.
Asegúrate de que las actividades de procesamiento de tus scripts de terceros estén en línea con las expectativas de estos marcos: transparencia, limitación de la finalidad y protección de datos. Eso significa que necesitas entender exactamente cómo se comportan los scripts de terceros, para poder divulgarlos con precisión en tus avisos de privacidad. Por defecto, los scripts solo deben recopilar los datos necesarios (en línea con el acceso de mínimo privilegio) y las medidas de seguridad deben proteger a los usuarios de la exfiltración de datos del lado del cliente.
Un buen punto de partida es revisar los DPA de cada proveedor de terceros que añadas a tu sitio. Estos documentos describen cómo tienen previsto procesar los datos recopilados de tus usuarios. Para garantizar que su actividad real se ajusta a lo esperado, se puede desplegar una herramienta de monitorización de scripts de terceros como cside.
Por qué los sitios web dependen de JavaScript de terceros
Es una buena práctica empresarial que los constructores no fabriquen sus propios ladrillos, sino que confíen en expertos para los materiales y la ingeniería. Lo mismo ocurre con los desarrolladores web: utilizan herramientas de terceros para analítica, pagos en línea, widgets y otras funcionalidades que hacen que los sitios web sean dinámicos e interactivos.
No hay necesidad de reinventar soluciones que ya existen. Las herramientas especializadas hacen el trabajo para que los equipos web puedan centrarse en el negocio principal en lugar de en la interfaz de usuario, las pruebas A/B, los flujos de pago en línea, la analítica, el seguimiento de ubicación, etc.
Por qué los scripts de terceros son un riesgo importante para la seguridad del lado del cliente
El problema de los privilegios en los scripts de terceros
El problema es el siguiente: en el navegador, todo el JavaScript recibe el mismo trato.
El DOM no distingue entre tu código y el de un proveedor. Los scripts de terceros tienen el mismo acceso a los datos del usuario y a los campos de formulario que tu propio código de primera parte. Pueden leer campos de formulario, acceder a cookies, modificar el contenido de la página y realizar solicitudes de red.
Esa es precisamente la vulnerabilidad que buscan los actores maliciosos.
El problema de la cadena de suministro en los scripts de terceros
Esto significa que si la infraestructura de un proveedor se ve comprometida, se pueden inyectar scripts maliciosos directamente en tu sitio web.
En la mediana, el 21% de los scripts en páginas móviles se inyectan de forma dinámica. En el percentil 90, el número de scripts llega incluso al 70%. En escritorio, las cifras son comparables.
Los scripts inyectados pueden crear un punto ciego de seguridad porque quedan fuera del perímetro de las herramientas de seguridad web tradicionales. Además, implica que los scripts de terceros inyectados dinámicamente pueden incluso inyectar scripts adicionales que nunca aprobaste.
una brecha en uno de tus proveedores = una brecha en tu aplicación
Aún peor: un script comprometido puede propagarse a todos los sitios web que lo utilizan. Una sola debilidad en un script de uso generalizado puede convertirse en un ataque a gran escala a la cadena de suministro.
