Resumen: mejores prácticas de seguridad de scripts de terceros
- En todas partes, con todos los privilegios: 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.
- La brecha del proveedor es tu brecha: 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.
- Cuatro prácticas para aplicar: 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.
- Dónde encaja una herramienta especializada: 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.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Mejores prácticas para proteger scripts de terceros en páginas web
Según el Web Almanac 2024 de HTTP Archive en general, 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 de seguridad de scripts de terceros, sin sacrificar velocidad ni funcionalidad, para que puedas proteger el JavaScript de terceros del que depende tu sitio.
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.
Para equipos que gestionan scripts en muchas propiedades, la monitorización de scripts de terceros en más de 100 dominios cubre patrones de detección multidominio en la práctica.
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.
Las organizaciones sanitarias también deben cumplir con las obligaciones de cumplimiento HIPAA para el seguimiento web cuando hay píxeles de terceros en páginas destinadas a pacientes, y leyes de privacidad estatales de EE. UU. como la Texas Data Privacy and Security Act exigen transparencia a nivel de scripts para las empresas que atienden a residentes de Texas.
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 como buena práctica es entender 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, despliega una herramienta de monitorización de scripts de terceros como cside.
¿Qué es el riesgo de cuarto partido?
El riesgo de cuarto partido es la exposición de seguridad y cumplimiento creada por scripts, píxeles y servicios que cargan tus proveedores de terceros: las dependencias de tus dependencias. Cuando integras una plataforma de gestión de etiquetas, esta puede cargar scripts adicionales de proveedores de analítica, redes publicitarias y herramientas de optimización. Esos scripts de cuarto partido reciben el mismo acceso a tu DOM, formularios y datos de usuario que el código incluido directamente, pero quedan completamente fuera de la mayoría de los programas de gestión de riesgo de proveedores y de los inventarios de CSP.
El problema práctico: auditas tu código de primera parte. Revisas a los proveedores de terceros antes de añadirlos. Pero cuando tu gestor de etiquetas carga un píxel de marketing, y ese píxel carga un script de retargeting, y ese script carga un SDK de optimización, tienes tres capas de código ejecutándose en los navegadores de tus usuarios que nunca aprobaste y que quizá ni sepas que existen.
Por qué CSP no lo detecta: una Content Security Policy incluye en lista blanca dominios, no código. Si tu gestor de etiquetas está en la lista blanca, todo lo que ese gestor de etiquetas carga está permitido por tu CSP, incluidos los scripts de cuarto partido que el proveedor añadió a su propia plataforma sin notificártelo. Detectar el riesgo de cuarto partido requiere un inventario en tiempo de ejecución: observar qué carga realmente cada script en sesiones reales, en lugar de comprobar los dominios de origen contra una lista estática.
El inventario de scripts de cside captura cada script de la cadena de ejecución (de primera, tercera y cuarta parte) en cada sesión real. Cualquier script que no esté en el inventario aprobado genera una alerta antes de que pueda acceder a campos de formulario o exfiltrar datos.
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.
Lecturas relacionadas: el clúster de seguridad de scripts de terceros
Usa este artículo como punto de partida y profundiza en las partes concretas de la seguridad de scripts de terceros que más importan a tu equipo:
- Un marco de gestión de riesgos de scripts de terceros convierte estas mejores prácticas en un proceso de gobernanza repetible.
- ¿Qué es la inyección de JavaScript? explica la técnica de ataque que permite a un script comprometido ejecutar código no aprobado en el navegador.
- Ataques Magecart explicados: web skimming cubre la forma más común en que se convierten los scripts de terceros en un arma contra las páginas de pago y checkout.
- Seguridad del lado del cliente de cside muestra cómo un único fragmento de JavaScript propio ofrece el inventario, los controles de mínimo privilegio, las verificaciones de integridad y la monitorización en tiempo de ejecución en un solo despliegue.
- Cumplimiento de PCI DSS con cside relaciona la seguridad de scripts de terceros con los requisitos de evidencia 6.4.3 y 11.6.1 de PCI DSS para las páginas de pago.
