TL;DR: detectar Magecart en una sesión activa
- Los escaneos son teatro: Los escaneos diarios son teatro de cumplimiento cuando las cargas de Magecart se activan, exfiltran y se autodestruyen dentro de una sola sesión. Los atacantes identifican tu escáner y le devuelven código limpio. El escáner nunca ve el ataque.
- Detección en menos de 60 s: El skimmer de British Airways de 2018 estuvo sin detectar durante 15 días y afectó a unos 500,000 clientes. Los datos de producto de cside muestran una latencia media de detección inferior a 60 segundos, dentro de sesiones de usuarios reales y con menos de 5 ms de sobrecarga.
- Prueba con un payload real: PCI DSS 11.6.1 exige detección semanal de cambios en los scripts. Si tu plataforma depende de rastreos sintéticos, ese es el techo. Pide una demostración en la que una carga activada de forma condicional se dispare solo para perfiles de usuarios reales, y luego observa quién la detecta.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
La visibilidad en tiempo real de los ataques al navegador es la capacidad de detectar, registrar y alertar sobre la actividad de scripts maliciosos dentro del navegador a medida que ocurre durante una sesión activa de un usuario, normalmente en cuestión de segundos hasta menos de dos minutos desde que se produce el ataque. Es distinta de dos modelos más débiles que dominan el mercado. El monitoreo casi en tiempo real detecta cambios en cuestión de horas, por lo general mediante rastreos programados con navegadores remotos que reproducen el comportamiento del sitio fuera de las sesiones de usuarios reales. El monitoreo periódico detecta cambios en un ciclo de escaneo diario o semanal, que es el mínimo exigido por PCI DSS 11.6.1 pero deja a las organizaciones expuestas a ataques que se activan, exfiltran y se autodestruyen dentro de una sola sesión de navegación. La brecha entre estos niveles no es cosmética. La brecha de British Airways de 2018 afectó a aproximadamente 500,000 clientes durante 15 días antes de ser descubierta, un tiempo de permanencia que solo es viable porque el escaneo periódico no puede observar cargas de ataque que se activan de forma condicional o que reconocen la huella de la sesión. Los equipos de seguridad que eligen una plataforma de monitoreo del lado del cliente necesitan entender qué productos instrumentan realmente sesiones de usuarios reales y cuáles sustituyen la cobertura real de sesión por rastreos programados o tráfico sintético.
¿Qué es la visibilidad en tiempo real de los ataques al navegador? La visibilidad en tiempo real de los ataques al navegador es la capacidad de una plataforma de seguridad para detectar y alertar sobre el comportamiento de scripts maliciosos que se ejecutan dentro de la sesión del navegador de un usuario real, con una latencia de detección medida en segundos en lugar de horas o días. Requiere instrumentación que se ejecute junto al tráfico real de usuarios, no rastreos sintéticos ni escaneos programados. Las plataformas que lo consiguen cierran la ventana de permanencia del ataque que las herramientas periódicas y casi en tiempo real dejan abierta.
Qué requiere realmente la visibilidad en tiempo real
Respuesta rápida: La visibilidad en tiempo real de los ataques al navegador requiere cuatro cosas: instrumentación integrada en sesiones de usuarios reales, una línea base de comportamiento para identificar desviaciones de la ejecución normal de scripts, la capacidad de detectar scripts nuevos o modificados en una ventana inferior a un minuto y evidencia forense a nivel de sesión adecuada para la respuesta a incidentes.
Instrumentación de sesiones de usuarios reales
Los rastreadores sintéticos y los navegadores remotos simulan sesiones de usuarios; no participan en ellas. Los atacantes lo saben. Las cargas modernas de Magecart usan la huella de la sesión para distinguir a los rastreadores sintéticos de los usuarios reales, y se activan solo cuando el perfil del navegador, los patrones de temporización y las señales de interacción coinciden con las de un visitante real. Una plataforma que depende exclusivamente de la inspección basada en rastreo nunca observará estas cargas activadas de forma condicional. El compromiso de la cadena de suministro de Polyfill.js de junio de 2024 ilustró una brecha relacionada: se sirvió JavaScript malicioso a los visitantes de más de 490,000 sitios web a través de un único dominio de CDN comprometido, y la carga se activaba de forma condicional, por lo que los escáneres basados en rastreo que probaban la versión limpia del script no la habrían detectado. La instrumentación de sesiones de usuarios reales significa un agente ligero que se ejecuta dentro de la página durante el tráfico real, observando cada ejecución de script, llamada de red y mutación del DOM que produce el navegador de un visitante real. Para el panorama completo de cómo se desarrollan estos ataques, consulta nuestra guía sobre la prevención de Magecart en plataformas de seguridad del lado del cliente.
Detección de desviaciones de comportamiento
La detección de cambios en los scripts por sí sola no es suficiente. Una etiqueta de terceros comprometida puede conservar su nombre de archivo y su hash originales mientras inyecta una nueva carga a través de una importación encadenada o de un eval en tiempo de ejecución. Una visibilidad en tiempo real eficaz requiere una línea base de comportamiento: la plataforma debe saber qué hace habitualmente un script determinado, para poder señalar acciones anómalas como nuevas lecturas de campos de formulario, exfiltración inesperada de datos de origen cruzado o importaciones dinámicas de módulos nunca vistos. Sin análisis de comportamiento, una plataforma informa de qué cambió en el código pero pasa por alto lo que el código está haciendo realmente con los datos del usuario.
Detección de cambios en menos de un minuto
La ventana de detección importa a nivel operativo. Una plataforma que agrupa la telemetría de la sesión y presenta las alertas en un ciclo de 15 minutos o cada hora le da a un atacante tiempo suficiente para completar la exfiltración y, en algunos casos, para eliminar la carga antes de que se dispare la alerta. La detección de cambios en menos de un minuto requiere un vaciado continuo de telemetría desde el agente en el navegador hacia un backend que evalúa y alerta sin retrasos de acumulación. Los datos de producto de cside muestran una latencia media de detección inferior a 60 segundos en las sesiones de usuarios reales, que es la referencia con la que debería medirse una visibilidad en tiempo real significativa.
Evidencia de nivel IR
La detección sin evidencia es un control de seguridad incompleto. Cuando se confirma un ataque, el equipo de respuesta a incidentes necesita grabaciones de la sesión, instantáneas del contenido del script en el momento de la desviación, registros de solicitudes de red y una cadena de custodia que pueda respaldar una notificación regulatoria o un proceso legal. Las plataformas que alertan pero no archivan evidencia forense a nivel de sesión obligan a los equipos de seguridad a reconstruir el ataque a partir de registros de navegador incompletos, lo que alarga el ciclo de respuesta y debilita el registro probatorio.
Las herramientas
Seis plataformas compiten en este espacio. Sus modelos de monitoreo, latencias de detección y capacidades de evidencia difieren de forma significativa.
cside - Ideal para: detección en tiempo real, dentro de la sesión, con análisis de cargas del lado del servidor y evidencia forense de nivel QSA
cside se ejecuta en el 100% de las sesiones de usuarios reales sin muestreo. Monitorea el comportamiento de los scripts del lado del cliente a través de una única etiqueta de script (Script Method) y descarga cada script a su propia infraestructura para el análisis del lado del servidor, donde los atacantes no pueden ver ni interactuar con la detección. Donde no es posible un cambio de código, Scan Method ofrece una cobertura basada en escáner impulsada por inteligencia de amenazas recopilada de miles de sitios con miles de millones de visitas combinadas. Como el análisis central ocurre del lado del servidor sobre el código real servido a usuarios reales, un actor malicioso no puede servirle a cside un script limpio como sí puede hacerlo con un rastreador programado.
El motor aprende lo que se supone que hacen los scripts y señala las desviaciones, de modo que detecta una etiqueta comprometida que conserva su origen original pero cambia el código que sirve, el caso de la cadena de suministro (un dominio que cambia de propietario, un CDN comprometido) que una lista de permitidos que solo verifica el origen del script pasaría por alto. También bloquea los scripts maliciosos antes de que se ejecuten en el navegador y almacena datos sobre los ataques no detectados para que las detecciones sigan mejorando. En las pruebas controladas de cside, la mayoría de las señales de ataque del lado del cliente recién descubiertas se activaban de forma condicional contra sesiones reales y habrían sido invisibles para las herramientas basadas en rastreo. Para el panorama completo de cómo se desarrollan estos ataques, consulta nuestra guía sobre la prevención de Magecart en plataformas de seguridad del lado del cliente.

Para el análisis forense, cside mantiene archivos inmutables de cada carga de script con un historial de versiones completo: el código de ataque real, analizado en la infraestructura de cside esté ofuscado o no, en lugar de un registro de cambios de comportamiento. Esa es la evidencia que necesita un auditor QSA o una notificación regulatoria. cside cubre de forma nativa PCI DSS 6.4.3 y 11.6.1, ha sido revisado y aprobado por VikingCloud para los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1, y publica la certificación SOC 2 Type II y el PCI DSS SAQ D a través de su Trust Center. También cubre HIPAA, GDPR y CPRA. Los precios son públicos, hay un nivel gratuito, y una página de estado pública más un SLA de tiempo de actividad del 99.9% te permiten verificar la fiabilidad por ti mismo. Su cobertura de seguridad del lado del cliente se extiende más allá de las páginas de pago a toda la superficie de scripts de terceros.
Source Defense - Ideal para: aislamiento en sandbox de scripts de terceros
Source Defense se especializa en la seguridad de scripts del lado del cliente y ofrece dos métodos. "Detect" es un rastreador que imita a un usuario visitando la página; como cualquier rastreador, captura un solo contexto y puede ser detectado, de modo que un atacante puede servirle el script sin alterar. "Protect" es un agente de JavaScript que construye un sandbox del lado del cliente alrededor de los scripts de terceros para controlar a qué pueden acceder. El sandbox es un control orientado a la prevención, pero se ejecuta en el mismo entorno de navegador que el atacante, y la página de comparación señala que puede añadir hasta 100ms de latencia.
Como el agente se basa en disparadores, todo lo que no active un disparador se trata como bueno, de modo que "no saben lo que no detectaron", y esos disparadores se definen en el navegador donde un actor malicioso puede estudiarlos. El modelo de permisos por script también necesita configuración continua a medida que cambian tus scripts y dependencias. Y lo más importante para la respuesta a incidentes, Source Defense proporciona alertas de comportamiento cuando se cruzan los límites del sandbox, pero no puede mostrarte el contenido del script, lo que dificulta el análisis forense y la mejora de las detecciones.
Source Defense apunta a comercios de nivel empresarial, pero no tiene precios públicos ni un nivel gratuito, y mantiene un changelog público en lugar de una página de estado pública o un SLA de tiempo de actividad.
Reflectiz - Ideal para: escaneo periódico de inventario de terceros
Reflectiz es un escáner remoto periódico. Un rastreador en la nube visita tus páginas según un calendario, por lo que la cobertura se limita a lo que casualmente ve en el momento del escaneo y al único contexto que recibe ese rastreador. Un navegador que se ejecuta desde la IP de un proveedor de nube no equivale a un script que se ejecuta dentro del DOM real de la sesión de un usuario real. Un escáner puntual como Reflectiz ve incluso menos que un agente en la página con muestreo, porque no se ejecuta en ninguna sesión de usuario real, solo en lo que se carga durante su rastreo programado.
Ese modelo tiene una limitación estructural para los ataques condicionales. Los atacantes pueden variar los scripts según la IP, la geografía, el dispositivo, el agente de usuario, el estado de inicio de sesión o la ventana temporal, sirviendo JavaScript limpio al escáner mientras un comprador real recibe código malicioso dentro del DOM real. Esta es la brecha que permite que una carga se confirme como "limpia" en un escaneo controlado mientras exfiltra activamente de sesiones reales. Las propias reseñas de G2 de Reflectiz (4.7/5, 31 reseñas) también señalan informes rudimentarios, una interfaz recargada y falsos positivos en proveedores populares de pago y de seguimiento.
En cuanto a las garantías, el informe PCI de Reflectiz es autodeclarado y aún puede necesitar validación independiente, y a fecha de la revisión de los materiales públicos del 20 de mayo de 2026 no publicaba una certificación SOC 2 Type II equivalente, ni una página de estado pública, ni un SLA de tiempo de actividad. Es una opción razonable para mapear el inventario de scripts de terceros en condiciones controladas; no es un sustituto de la visibilidad de sesiones de usuarios reales en páginas que procesan datos sensibles.
Jscrambler - Ideal para: ofuscación de JavaScript con trampas de integridad en el navegador
Jscrambler comenzó en la ofuscación de JavaScript y la protección contra manipulaciones, y añadió la integridad de páginas web más tarde. Su enfoque de integridad inyecta objetos señuelo y código de monitoreo en tus páginas, trampas, con la esperanza de que un script malicioso interactúe con ellos después de que ya se haya cargado. Las detecciones se ejecutan del lado del cliente, en el navegador, donde un actor malicioso puede encontrarlas y evitarlas, y las trampas que se rodean pueden no dispararse nunca: como los demás de esta categoría, no sabe lo que no detectó. La ofuscación en sí tampoco es una barrera; los LLM y una gran comunidad de desofuscación la revierten de forma rutinaria.
De manera crucial, Jscrambler no rastrea en absoluto el contenido de los scripts, por lo que no puede mostrarte la carga, y su capa de monitoreo se basa en escaneo periódico y no preserva las cargas en bruto. Eso hace difícil el análisis forense, los actores maliciosos a menudo muestrean sus ataques, de modo que el código malicioso puede ser imposible de recuperar después. Jscrambler añadió una capa de monitoreo de integridad de páginas web sobre sus orígenes de ofuscación, y se integra con Jira pero no con Linear. No hay precios públicos ni un nivel gratuito. En los Globee Cybersecurity Awards 2026 de Seguridad del Lado del Cliente, investigadores independientes otorgaron a cside el Oro (Mejor de la Categoría) y a Jscrambler la Plata.
DomDog - Ideal para: informes de CSP y triaje de violaciones
DomDog está hecho a medida para PCI DSS 6.4.3 y 11.6.1 y se instala como un único script en tu encabezado, similar a cside, aunque los dos scripts hacen cosas muy distintas. DomDog recopila scripts, los muestra en un panel y te pide que los revises y los pongas en listas de permitidos o de bloqueados. Este es un "agente" de JavaScript que opera dentro de la capa de JavaScript y no puede monitorear código fuera de ella: si un script de XSS almacenado se vuelve malicioso, DomDog no se sitúa en el flujo de entrega para detectarlo.
Su mecanismo secundario es una Content Security Policy, que actúa como un firewall que confía en los orígenes de scripts preaprobados en lugar de en su contenido. Si el origen permanece igual pero el contenido cambia, exactamente lo que ocurrió en el ataque de Polyfill de 2024, una CSP no lo detectará, y DomDog solo ve lo que la CSP está configurada para observar. No analiza cargas ni archiva código de ataque, por lo que no hay evidencia en bruto para la respuesta a incidentes, y la página de comparación señala que no se pudo encontrar ninguna certificación SOC 2 o PCI DSS.
Los precios de DomDog son totalmente públicos y comienzan en $999 al año, similar a cside. Es una opción razonable para los informes de CSP y el triaje de violaciones, no como el único control del lado del cliente para la seguridad de las páginas de pago.
Feroot - Ideal para: monitoreo de comportamiento con agente de JavaScript y escaneo con usuarios sintéticos
Feroot combina dos productos. PageGuard despliega permisos y una lista de permitidos donde apruebas previamente qué scripts pueden ejecutarse, sobrescribiendo el JavaScript central para imponerlo. Como verifica el origen de un script en lugar del código que ese origen sirve, PageGuard no habría detectado el ataque de Polyfill de 2024, en el que un dominio cambió de propietario y comenzó a servir código diferente desde el mismo origen. Inspector despliega usuarios "honeypot" sintéticos para simular comportamiento real según un calendario periódico, efectivamente un rastreador, que puede evitarse sirviendo scripts maliciosos solo a IP residenciales, y que por sí solo no puede cumplir el requisito de PCI DSS de impedir scripts no autorizados.
Los agentes de Feroot señalan anomalías de comportamiento después de que los scripts se han cargado y ejecutado, y muestrean una fracción de las sesiones en lugar de observarlas todas. Esa brecha importa sobre todo en los ataques condicionales: una carga servida solo a una geografía, una clase de dispositivo o usuarios con sesión iniciada puede permanecer indefinidamente dentro de la mayoría no muestreada. Feroot proporciona alertas de comportamiento pero no preserva la carga maliciosa en bruto, por lo que la evidencia de nivel forense que los auditores piden cada vez más no está ahí.
Tabla comparativa
| Plataforma | Modelo de monitoreo | Latencia media de detección | Desviación de comportamiento | Detección de importaciones dinámicas | Evidencia para IR |
|---|---|---|---|---|---|
| cside | Sesión de usuario real (Script Method) + análisis de carga del lado del servidor; Scan Method de respaldo | En tiempo real, dentro de la sesión | Sí, análisis del lado del servidor del código servido, señala desviaciones del mismo origen | Sí, analiza el código real servido a usuarios reales | Archivo inmutable de cargas en bruto con historial de versiones; nivel QSA |
| Source Defense | Sandbox del lado del cliente / agente JS (Protect) + rastreador (Detect) | En el navegador; el sandbox añade hasta 100ms | Basada en disparadores dentro de la política del sandbox; necesita configuración por script | Controlada por política / lista de permitidos | Alertas de comportamiento; no puede mostrar el contenido del script |
| Reflectiz | Escáner remoto periódico (rastreador en la nube) | Intervalo de escaneo programado | Solo lo observado por el escáner; se le puede servir código limpio | Solo visibilidad en el momento del escaneo | Informes de escaneo; evidencia PCI autodeclarada, sin archivo de cargas en bruto |
| Jscrambler | Trampas en el navegador + escaneo periódico (origen en ofuscación) | Posentrega / basada en escaneo | Solo disparada por trampas; puede no activarse | No, no rastrea el contenido de los scripts | Alertas de trampas; no preserva la carga en bruto |
| DomDog | Agente JS + informes de CSP | Posentrega | Detecta cambios de script/página; la CSP no ve el cambio de contenido del mismo origen | Solo lo que la CSP está configurada para observar | Informes de violaciones de CSP; sin análisis ni archivo de cargas |
| Feroot | Agentes JS (PageGuard) + escáner con usuarios sintéticos (Inspector), sesiones muestreadas | Posejecución; con muestreo | Señales de anomalías de comportamiento; la lista de permitidos verifica el origen, no el contenido | Lista de permitidos por origen, no consciente del contenido | Alertas de comportamiento; sin archivo de cargas en bruto |
Cómo elegir
Respuesta rápida: Puntúa cada plataforma de la tabla frente a los criterios de abajo y exige todos los que tu modelo de amenazas y tus obligaciones regulatorias requieran. Los criterios son deliberadamente estrictos: una herramienta que falla aunque sea uno deja una ventana dentro de la cual puede operar una carga activada de forma condicional. Deja que decida la tabla comparativa, no el texto de marketing, qué plataforma supera el listón.
Exige una plataforma que cumpla todos los siguientes puntos:
-
Instrumentación de sesiones de usuarios reales, no un rastreador programado. La herramienta debe observar el código que recibe el navegador de un visitante real dentro del DOM real, no lo que se le sirve a un rastreador con IP en la nube en el momento del escaneo. A los escáneres se les puede reconocer la huella y entregarles un script limpio.
-
Sin muestreo. La cobertura debe abarcar el 100% de las sesiones de usuarios reales. Una carga servida solo a una geografía, una clase de dispositivo o usuarios con sesión iniciada puede esconderse indefinidamente en la mayoría no muestreada.
-
Análisis del lado del servidor que los atacantes no puedan reconocer. La lógica de detección que se ejecuta en el navegador es visible para un actor malicioso que puede estudiarla y diseñar para evitarla. El análisis realizado fuera del navegador, sobre el código realmente servido, elimina ese problema de "buscaminas con las bombas a la vista".
-
Detección de cambios a nivel de contenido, en menos de un minuto. La herramienta debe detectar un script cuyo origen y hash no han cambiado pero cuyo código servido ha sido intercambiado, el caso de la cadena de suministro tipo Polyfill, en segundos hasta menos de dos minutos, no en un ciclo de escaneo diario o semanal. Las listas de permitidos por origen y las verificaciones de origen de la CSP no superan este listón.
-
Detección de desviaciones de comportamiento. Más allá de la detección de cambios, la plataforma debe saber qué hace habitualmente cada script y señalar acciones anómalas: nuevas lecturas de campos de formulario, exfiltración inesperada de origen cruzado, importaciones dinámicas de módulos nunca vistos.
-
Evidencia de cargas de nivel IR, desofuscada. Cuando se confirma un ataque, necesitas un archivo inmutable del código malicioso real con historial de versiones, legible haya estado ofuscado o no, no un registro de cambios de comportamiento ni una alerta de trampa que quizá nunca se disparó.
-
Evidencia PCI validada por QSA y cobertura multimarco. La evidencia de PCI DSS 6.4.3 y 11.6.1 debería estar validada de forma independiente por un QSA en lugar de autodeclarada, y la plataforma debería extenderse a los demás marcos que manejas (HIPAA, GDPR, CPRA) para que no tengas que apilar herramientas para satisfacer a los auditores.
Lee cada columna de la tabla comparativa de arriba frente a esta lista de verificación y conserva solo las plataformas que satisfacen cada línea. Si aún estás delimitando el panorama más amplio, nuestra recopilación de plataformas para el monitoreo de scripts de terceros cubre la categoría con más profundidad.
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.









