Resumen: monitorización de scripts
La monitorización de scripts es la observación continua de lo que JavaScript ejecuta en el navegador de un visitante en tiempo de ejecución: qué scripts se cargan, a qué datos acceden, dónde escriben y qué scripts importan dinámicamente. A diferencia del inventario o las comprobaciones de hash, la monitorización de scripts rastrea el comportamiento para que un script de proveedor comprometido sea detectado no por un cambio de URL, sino por cambios en sus acciones.
- Lo que exige PCI DSS: El inventario continuo y la detección de cambios que PCI DSS 4.0.1 exige para cada script en una página de pago.
- Más allá de las allowlists: Las listas de permitidos estáticas no detectan dominios de confianza comprometidos. La detección real significa observar lo que el script realmente lee y transmite, durante la sesión.
- Qué buscar: sensor de primera parte, diferencia de carga útil y no solo hash, tasa baja de falsos positivos con tráfico real, exportaciones de evidencia para QSA.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Qué requiere una monitorización eficaz de scripts de terceros
Respuesta rápida: Una monitorización eficaz de scripts de terceros va más allá de rastrear qué scripts están presentes. Detecta cambios en lo que los scripts hacen en tiempo de ejecución: los datos a los que acceden, los destinos a los que escriben, las importaciones dinámicas que cargan. Un compromiso de la cadena de suministro a menudo produce un nuevo hash desde un origen de confianza; solo la monitorización del comportamiento lo detecta.
El Top 10 2021 de OWASP incluye los fallos de integridad de software y datos, que abarcan los ataques a la cadena de suministro de software, como uno de los tres principales riesgos de las aplicaciones web (OWASP). Las cinco capacidades que importan específicamente para la monitorización de scripts de terceros son:
Cómo un compromiso de la cadena de suministro llega al navegador:
- El atacante compromete la infraestructura de CDN del proveedor y modifica un script que cargan miles de sitios, por ejemplo
cdn.vendor.com/analytics.js. El comerciante nunca tocó el código. - El archivo modificado se distribuye como un archivo nuevo con un hash nuevo y válido desde el origen de confianza. CSP lo aprueba (el origen está autorizado). La monitorización de SRI / rotación de hash lo aprueba (se espera un nuevo hash de un proveedor conocido). El WAF / CDN lo aprueba (TLS válido, entrega legítima). Las comprobaciones de identidad ven un origen de confianza, no ven el comportamiento.
- El script se ejecuta en el navegador del visitante en el formulario de pago o compra y lee campos del formulario que nunca antes había leído.
- Envía por POST los datos robados de la tarjeta a un nuevo destino de red, el endpoint de exfiltración del atacante, que la línea base nunca incluyó.
- Solo la monitorización del comportamiento en tiempo de ejecución lo detecta. Un sensor en tiempo de ejecución de cside señala la desviación (una nueva lectura de campo de formulario más un nuevo destino saliente) en la primera sesión real en la que se ejecuta la versión comprometida. Las comprobaciones de identidad y de hash no pueden hacerlo, porque el script está autorizado pero comprometido.
Inventario estático frente al árbol de dependencias en tiempo de ejecución:
| Vista | Qué contiene |
|---|---|
| Estática, lo que la página declara | Tres etiquetas de script declaradas en el HTML de la página en la carga: analytics.js, tag-manager.js y cdn-vendor[.]example/widget.js. Este es todo el inventario que ve un escáner. |
| Tiempo de ejecución, lo que realmente se ejecuta | cdn-vendor[.]example/widget.js carga fonts.css y vendor-core.js; vendor-core.js luego importa dinámicamente import('cdn-metrics[.]example/p.js'). |
La carga útil importada dinámicamente, cdn-metrics[.]example/p.js, inyectada en tiempo de ejecución por vendor-core.js, nunca aparece en el inventario estático. Solo una plataforma que monitoriza el entorno de ejecución en tiempo real ve los niveles dos y tres del árbol de dependencias, que es donde se esconden las cargas útiles de la cadena de suministro.
Mapeo de relaciones con proveedores. La plataforma debe enumerar no solo qué scripts están presentes, sino qué proveedor entrega cada script, a través de qué infraestructura y qué otros scripts carga dinámicamente cada script. Un ataque a la cadena de suministro suele propagarse a través de un árbol de dependencias.
Línea base de comportamiento por script. Cuando el script de analítica del proveedor X se compromete, la nueva versión puede tener la misma URL y un nuevo hash de apariencia legítima, pero leerá campos del formulario de pago o escribirá a un nuevo destino de red. Detectar esto requiere una línea base de comportamiento, no solo una línea base de identidad.
Detección de importaciones dinámicas. Los scripts que cargan otros scripts en tiempo de ejecución son el vector de propagación de la cadena de suministro más común. Una plataforma que solo monitoriza los scripts declarados estáticamente en el HTML pasará por alto las dependencias de segundo nivel cargadas dinámicamente.
Monitorización del destino de red. La señal definitiva de un skimmer de cadena de suministro exitoso es una transmisión de datos a un destino que la línea base no incluía. Monitorizar las llamadas de red salientes de cada script (dominio, método, forma de la carga útil) es la señal de detección de cadena de suministro de mayor confianza.
Puntuación de riesgo de proveedores. No todos los proveedores conllevan el mismo riesgo de cadena de suministro. Una plataforma que asigna y actualiza continuamente puntuaciones de riesgo de proveedores basándose en el comportamiento observado, la seguridad de la infraestructura de entrega y los patrones históricos de compromiso ofrece a los equipos de seguridad una vista priorizada de su superficie de exposición a terceros.
Las plataformas
cside
Ideal para: Equipos de seguridad e ingeniería que necesitan visibilidad completa de la cadena de suministro de JavaScript de terceros en tiempo de ejecución, con línea base de comportamiento, detección de importaciones dinámicas y archivado de cargas útiles de grado forense.
cside añade un script a tu sitio, monitoriza lo que hace cada script de terceros en sesiones de usuarios reales y descarga cada script a su propia infraestructura para el análisis del lado del servidor. Como el análisis central ocurre fuera de la página, permanece invisible para los atacantes: no hay ninguna trampa o gancho en el navegador que puedan estudiar, desactivar o rodear. cside construye una línea base de comportamiento para cada script, rastreando lecturas del DOM, adjuntos de gestores de eventos, escrituras de red e importaciones dinámicas, y señala la desviación de esa línea base en la primera sesión de usuario real en la que se ejecuta una versión comprometida.
La cobertura es del 100 % de las sesiones de usuarios reales sin muestreo, lo que más importa para los ataques condicionales: una carga útil servida solo a una geografía, una clase de dispositivo o usuarios autenticados. La detección de importaciones dinámicas alcanza el segundo y tercer nivel del árbol de dependencias, la ruta de propagación más común para los ataques a la cadena de suministro, y cada carga útil se conserva en un archivo inmutable para que la respuesta a incidentes y los auditores QSA obtengan el código de ataque real en lugar de un registro de comportamiento. El mismo motor ayuda a los equipos a cumplir los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1, además de HIPAA, GDPR y CPRA. Los precios son públicos y hay un nivel gratuito. Este enfoque en tiempo de ejecución es el mismo modelo que hay detrás de las herramientas de visibilidad de ataques al navegador en tiempo real y la categoría más amplia de seguridad del lado del cliente.
En los Premios Globee® de Ciberseguridad 2026, jueces independientes nombraron a cside ganadora del Globee® de Oro (Mejor de la Categoría) en Seguridad del Lado del Cliente; Jscrambler recibió la Plata. Consulta el desglose cara a cara de cside vs Jscrambler.
Jscrambler
Ideal para: Equipos de desarrollo que quieren proteger su propio JavaScript de primera parte frente a la manipulación, además de monitorizar los scripts de terceros.
Jscrambler comenzó en la ofuscación de JavaScript, transformando el código de primera parte para dificultar su ingeniería inversa, y añadió su capa de monitorización Webpage Integrity más tarde. Para los equipos que también necesitan proteger lógica en el navegador propietaria, aplicación de licencias o algoritmos, el portafolio combinado es un atractivo genuino, y el desglose de cside vs Jscrambler cubre esa superposición en detalle.
Por el lado de la cadena de suministro, la monitorización se basa en trampas: Jscrambler inyecta objetos señuelo y código de monitorización en tus páginas y espera a que un script malicioso interactúe con ellos después de haberse cargado ya. Esas trampas se ejecutan en el navegador, donde un atacante motivado puede verlas, ignorar los señuelos o bloquear el endpoint de devolución de llamada. Como Jscrambler no rastrea el contenido de los scripts, no puede mostrarte la carga útil tras un incidente, lo que limita el análisis forense. cside ejecuta su análisis del lado del servidor, donde los atacantes no pueden verlo, y archiva el código malicioso real para su revisión. Jscrambler recibió el Globee® de Plata frente al Oro de cside en la categoría de Seguridad del Lado del Cliente 2026.
Source Defense
Ideal para: Comerciantes empresariales que quieren contener los scripts de terceros mediante aislamiento y sandboxing del lado del cliente.
Source Defense, fundada en 2014, asegura los scripts de terceros de dos maneras. "Source Defense Detect" es un rastreador que imita a un visitante y obtiene los scripts que carga una página; como un rastreador es solo un contexto (ubicación, dispositivo, hora), no puede capturar la carga útil exacta que recibe un visitante real, y un atacante puede servir un script limpio siempre que la solicitud parezca provenir de un proveedor de nube. "Source Defense Protect" es un agente de JavaScript que construye un sandbox del lado del cliente para restringir a qué puede acceder un script en la página.
La idea del sandbox es sólida, pero se ejecuta en el mismo entorno de navegador que el atacante, por lo que un script malicioso que ya se está ejecutando puede sobrescribir funciones básicas como fetch y cortar las propias alertas del agente. El desglose de cside vs Source Defense también señala hasta 100 ms de latencia añadida y el punto ciego basado en disparadores donde todo lo que no se activa se asume bueno. Como otras herramientas basadas en agentes, Source Defense no puede mostrarte el contenido del script, lo que limita el análisis forense. cside analiza cada script del lado del servidor antes de que se confíe en él, mantiene el 100 % de cobertura de sesiones sin muestreo y conserva la carga útil bruta como evidencia.
DomDog
Ideal para: Equipos que quieren una herramienta enfocada y de bajo coste dirigida directamente a PCI DSS 6.4.3 y 11.6.1, con precios transparentes.
DomDog está hecho a medida para los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 y, algo inusual en este espacio, publica sus precios abiertamente, a partir de 999 $ al año, similar a cside. La configuración es un único script en la etiqueta del encabezado. Recopila los scripts que se ejecutan en tus páginas, los muestra en un panel y te pide que los revises y los pongas en lista de permitidos o de bloqueados, respaldado por una capa secundaria de Content Security Policy (CSP).
Ese diseño es un "agente" de JavaScript que no se sitúa en el flujo de entrega de scripts, por lo que un script de XSS almacenado que se vuelve malicioso más tarde puede pasar sin ser detectado, y la capa CSP solo confía en el origen de un script, no en el código servido: no detectaría un origen que mantiene su dominio pero cambia su contenido, como en el ataque Polyfill. El desglose de cside vs DomDog tampoco pudo encontrar una certificación SOC 2 o PCI DSS para DomDog. cside se sitúa en la ruta de entrega, descarga y analiza la carga útil real del lado del servidor, la archiva y cubre marcos más allá de PCI, incluidos HIPAA, GDPR y CPRA.
Feroot Security
Ideal para: Equipos orientados al cumplimiento que quieren un monitor de comportamiento basado en agente de JavaScript para la visibilidad de scripts de PCI DSS.
Feroot, fundada en 2017, divide su oferta en dos productos. "PageGuard" despliega permisos y una lista de permitidos donde apruebas previamente qué scripts pueden ejecutarse en qué páginas, sobrescribiendo JavaScript básico para aplicar la política. Como una lista de permitidos solo comprueba el origen de un script, no el código servido, el desglose de cside vs Feroot señala que PageGuard no habría detectado el ataque Polyfill, donde un dominio de confianza cambió de manos y empezó a servir código nuevo. "Inspector" despliega usuarios señuelo sintéticos para simular comportamiento real; es efectivamente un escáner que ejecuta comprobaciones periódicas, y un rastreador puede evadirse sirviendo el script malicioso solo a direcciones IP residenciales.
Los agentes de Feroot señalan anomalías de comportamiento después de que los scripts se hayan cargado y muestrean solo una fracción de las sesiones, por lo que una carga útil servida a una geografía, una clase de dispositivo o usuarios autenticados puede quedar en la mayoría no muestreada indefinidamente. cside descarga cada script para el análisis del lado del servidor en tiempo real en el 100 % de las sesiones sin muestreo, y archiva cada carga útil para el análisis forense y la evidencia de PCI.
Comparativa de un vistazo
| Plataforma | Línea base de comportamiento | Detección de importaciones dinámicas | Monitorización del destino de red | Puntuación de riesgo de proveedores | Evidencia desofuscada |
|---|---|---|---|---|---|
| cside | Sí | Sí | Sí | Parcial | Sí |
| Jscrambler | Parcial | No documentado en esta comparativa | No documentado en esta comparativa | No | No |
| Source Defense | Sandboxing | No documentado en esta comparativa | No documentado en esta comparativa | No documentado en esta comparativa | No |
| DomDog | Solo DOM | No | No | No | No |
| Feroot | Limitada | No | No documentado en esta comparativa | No | No |
Cómo elegir
Respuesta rápida: No partas de un nombre de producto. Decide tu objetivo de control principal y luego exige las capacidades de las que depende. Puntúa cada herramienta de la tabla comparativa con la misma lista de verificación y deja que la que cumpla todos tus requisitos imprescindibles se seleccione sola.
Usa esta lista de verificación. Los criterios que separan un control real de la cadena de suministro de un panel de inventario son los que una carga útil comprometida y ofuscada no puede eludir:
- Línea base de comportamiento en sesiones en vivo. La herramienta aprende lo que cada script hace normalmente (lecturas del DOM, gestores de eventos, escrituras de red) y señala la desviación, en lugar de solo comprobar la identidad o el hash de un script.
- Cobertura del 100 % de las sesiones de usuarios reales, sin muestreo. Los ataques condicionales sirven la carga útil maliciosa solo a una geografía, clase de dispositivo o usuarios autenticados. Cualquier cosa por debajo de la cobertura total puede dejar esa carga útil en la mayoría no muestreada indefinidamente.
- Rastreo de importaciones dinámicas. La detección alcanza el segundo y tercer nivel del árbol de dependencias, scripts cargados por scripts, que es la ruta de propagación de la cadena de suministro más común.
- Monitorización del destino de red. Las llamadas salientes por script (dominio, método, forma de la carga útil) se rastrean, de modo que la exfiltración a un nuevo destino se detecta incluso cuando el origen del script está autorizado.
- Análisis de cargas útiles del lado del servidor que los atacantes no pueden identificar ni eludir. La detección central se ejecuta fuera de la página, por lo que no hay trampas, ganchos ni agentes en el navegador que un atacante pueda ver, desactivar o sobrescribir.
- Archivado de cargas útiles desofuscadas para análisis forense. El código malicioso real se captura y conserva en un registro inmutable, no solo un registro de cambios de comportamiento, para que la respuesta a incidentes y un QSA obtengan la evidencia real.
- Evidencia de grado QSA para PCI DSS 6.4.3 y 11.6.1, idealmente junto con HIPAA, GDPR y CPRA, para que un solo control sirva a múltiples marcos de cumplimiento.
- Funciona en cualquier CDN con un único script y sin mantenimiento de listas de permitidos, evitando la escritura de reglas por script y el bloqueo con el proveedor a medida que cambian tus integraciones.
- Precios transparentes y un nivel gratuito, para que puedas validar la cobertura con tu propio tráfico antes de comprometer presupuesto.
Pondera la lista de verificación hacia tu objetivo principal, luego lee la tabla comparativa de arriba y elige la herramienta que satisfaga cada requisito imprescindible. Para la clase relacionada de ataques de skimming, consulta nuestro resumen de plataformas de seguridad del lado del cliente para la prevención de Magecart.
Prueba cside antes de comprar. cside tiene un plan gratuito, así que puedes registrarte, desplegarlo y explorar la plataforma por tu cuenta, sin llamadas de ventas ni procesos de compra. Y nuestro equipo de soporte está a un mensaje de distancia cuando necesites ayuda.
