TL;DR: detección de skimmers en la primera sesión afectada
- El CSP es un portero: Una Content Security Policy es un portero, no un guardaespaldas. Detiene la carga de nuevos scripts, pero deja pasar una etiqueta aprobada en la que un proveedor introdujo un skimmer durante la noche.
- Línea base de cada script de pago: La protección Magecart más sólida establece una línea base de comportamiento para cada script de la página de pago y alerta, en la misma sesión en la que cambia, cuando un script permitido empieza a tocar campos de formulario que nunca antes había tocado. Esa es la detección de manipulación en tiempo de ejecución que exige PCI DSS 4.0.1 Requisito 11.6.1, y que una CSP no puede ofrecer.
- La lista de verificación del comprador: Que una herramienta cierre realmente la brecha se reduce a una breve lista de verificación, cubierta en los criterios de compra más abajo: monitorización en tiempo real en sesiones de usuarios reales, detección de cambios de comportamiento en scripts ya aprobados, archivado de payloads desofuscados para análisis forense y evidencia validada por QSA para los Requisitos 6.4.3 y 11.6.1. Puntúa cada opción de la tabla comparativa frente a ella.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
El mejor software de protección contra Magecart vigila en tiempo real cada script de tu página de pago y lanza una alerta en el instante en que cualquier script, propio o de terceros, lee un campo de pago o envía datos a un endpoint que no debería. Una Content Security Policy impide que se carguen scripts desconocidos, pero no puede detectar un cambio de comportamiento dentro de un script que ya aprobaste, por lo que PCI DSS 4.0.1 ahora exige monitorización de integridad de scripts en tiempo de ejecución en las páginas de pago.
Los ataques Magecart comprometen la cadena de suministro de JavaScript en las páginas de pago. Un atacante inyecta código de skimming en un script de terceros que tu sitio ya carga y en el que confía (una etiqueta de analítica, un widget de chat, un píxel de marketing), y ese script empieza a recolectar datos de tarjetas de pago de los campos del formulario de checkout sin ningún cambio visible en la página. El checkout promedio carga docenas de scripts de terceros, y cada uno es un posible punto de inyección.
El PCI Security Standards Council concretó este riesgo en PCI DSS 4.0.1. El Requisito 6.4.3 obliga a inventariar y autorizar todos los scripts de las páginas de pago. El Requisito 11.6.1 obliga a la detección de manipulación, es decir, alertas automáticas cuando cualquier script de una página de pago cambia su comportamiento. Ambos requisitos pasaron a ser obligatorios el 2025-03-31.
| Herramienta | Monitorización de scripts en tiempo real | Detecta cambios de comportamiento en scripts aprobados | Archivo de payload desofuscado / evidencia forense | Evidencia PCI DSS 6.4.3 + 11.6.1 | Nivel gratuito |
|---|---|---|---|---|---|
| cside | Sí, 100% de las sesiones de usuarios reales, sin muestreo | Sí, línea base de comportamiento por script | Sí, archivo de payloads inmutable | Sí, validado por QSA (VikingCloud) | Sí (1,000 llamadas API/mes) |
| Reflectiz | Escáner remoto periódico, no sesiones de usuarios reales | Solo en el momento del escaneo | No documentado en esta comparativa | Informes autodescritos, pueden requerir validación independiente | No documentado en esta comparativa |
| Source Defense | Agente JS del lado del navegador más crawler | Sí, por comportamiento (lado del navegador) | No, no puede mostrar el contenido de los scripts | Registros de detección, no evidencia de payload de grado forense | No |
| Jscrambler | Escaneo periódico más trampas en el navegador | Basado en trampas, puede no dispararse | No, no rastrea el contenido de los scripts | Registros de comportamiento, sin evidencia de payload | No |
| DomDog | Agente de navegador más informes CSP | Por comportamiento; CSP no detecta cambios de contenido del mismo origen | No, sin análisis ni archivo de payload | Diseñado para 6.4.3 + 11.6.1, sin archivo de payload | No ($999/year de entrada) |
| Content Security Policy sola | No, bloquea nuevos scripts, no cambios de comportamiento | No | No | No | Gratis (nativa del navegador) |
Por qué una Content Security Policy es necesaria pero no suficiente
Una Content Security Policy (CSP) es una lista de permitidos aplicada por el navegador que bloquea la carga de scripts salvo que su origen esté explícitamente permitido. Para Magecart, una CSP impide que un atacante inyecte un nuevo script externo en una página de pago.
No impide que un atacante comprometa un script que ya está en la lista de permitidos. Si un atacante obtiene acceso al CDN o al repositorio de código de un proveedor externo que tu CSP ya permite, puede modificar el script de ese proveedor para incluir código de skimming. La CSP ve que el script se carga desde el mismo origen permitido y lo permite, así que el skimmer se ejecuta dentro de un script aprobado.
El Requisito 11.6.1 existe porque el PCI SSC reconoció esta brecha. Te pide detectar cuándo un script aprobado cambia lo que hace, lo que requiere monitorización de comportamiento en tiempo de ejecución. Una CSP no puede ofrecer eso.
cside: detección de Magecart en tiempo real
La protección Magecart de cside monitoriza en tiempo real cada script cargado en la página de pago. Establece una línea base de comportamiento para cada script aprobado (a qué elementos del DOM accede, a qué destinos de red llama, qué datos lee) y alerta en cuanto cualquier script se desvía de esa línea base.
Cuando un script de terceros comprometido empieza a acceder a campos del formulario de pago que no había tocado antes, cside detecta el cambio en la misma sesión en la que ocurre. La alerta identifica el script específico, el cambio de comportamiento concreto y la marca de tiempo, de modo que tienes evidencia utilizable en una evaluación PCI.
cside también mantiene el inventario de scripts que exige el Requisito 6.4.3: una lista completa y actualizada de forma continua de cada script presente en la página de pago, con el estado de autorización de cada uno. Como el inventario y la detección de manipulación se entregan en un único despliegue validado, una sola herramienta satisface ambos requisitos. cside está validado por VikingCloud para PCI DSS 4.0.1 Requisitos 6.4.3 y 11.6.1.
Para contextualizar, el skimming en páginas de pago sigue siendo un motor principal del compromiso de datos de tarjetas basado en la web para los comercios. Detectar la inyección Magecart en la primera sesión afectada es lo que evita que un solo proveedor comprometido se convierta en un incidente masivo de datos de tarjetas.
Reflectiz
Reflectiz es una plataforma de seguridad de sitios web que monitoriza los scripts de terceros en busca de cambios de comportamiento y riesgo. Su modelo de detección se basa en escaneos remotos periódicos desde infraestructura de crawler: un navegador que se ejecuta desde la IP de un proveedor de nube visita tus páginas según una programación e informa de lo que ve.
Para Magecart, ese modelo de escaneo programado es la limitación central. Un navegador desde una IP de nube conocida no equivale a un script ejecutándose dentro del DOM real de una sesión de usuario real, y los skimmers del lado del cliente se adaptan rutinariamente al visitante. Un atacante que identifique el escáner puede servirle una página limpia mientras los compradores reales reciben la versión maliciosa, así que un escáner puede crear una falsa sensación de cobertura entre escaneos. Un escáner puntual como Reflectiz ve incluso menos que un agente en página muestreado, porque no se ejecuta en ninguna sesión de usuario real, solo en lo que se cargue durante su rastreo programado. En cuanto a garantías, según los materiales públicos revisados el 2026-05-20, Reflectiz no publicaba una aprobación QSA equivalente, PCI DSS SAQ D ni certificación SOC 2 Type II, y no publica ninguna página de estado pública ni SLA de tiempo de actividad; su precio tampoco es público.
cside se ejecuta en el 100% de las sesiones de usuarios reales sin muestreo y descarga cada script a su propia infraestructura para su análisis del lado del servidor, de modo que un actor malicioso no puede servirle un script limpio como sí puede hacer con un crawler programado, y cada payload se archiva como evidencia. cside también ofrece cobertura basada en escáner mediante su Scan Method para casos en los que no es posible desplegar un script, pero no convierte el escaneo en todo el modelo de seguridad, y está validado por QSA por VikingCloud para PCI DSS 4.0.1 Requisitos 6.4.3 y 11.6.1.
Source Defense
Source Defense se especializa en seguridad de sitios web del lado del cliente y se dirige a comercios empresariales. Ofrece dos métodos para los scripts de las páginas de pago: Source Defense Detect, un crawler que imita a un usuario visitando la página para obtener los scripts de terceros que se cargan, y Source Defense Protect, un agente JavaScript que construye un sandbox del lado del cliente para aislar los scripts y limitar a qué pueden acceder.
Para Magecart, ambos métodos tienen brechas que un skimmer puede explotar. El crawler es solo una combinación específica de ubicación, dispositivo y momento, así que no captura el payload exacto que recibe un visitante real, y un atacante puede detectar la infraestructura de nube y servirle un script limpio. El agente JavaScript se basa en disparadores, así que todo lo que no active un disparador se trata como bueno, y como los disparadores se definen en el navegador, un actor malicioso puede estudiarlos y diseñar un skimmer que los evite. El sandbox añade hasta 100ms de latencia, y como el agente se ejecuta en el mismo entorno de navegador que el atacante, un script que ya se esté ejecutando puede sobrescribir funciones básicas como fetch y cortar la alerta antes de que salga de la página. Lo más importante para el análisis forense de skimming: Source Defense no puede mostrarte el contenido de los scripts, así que probar lo que hizo realmente un script comprometido es difícil.
cside analiza cada script del lado del servidor, en infraestructura que el atacante no puede ver ni con la que puede interactuar, así que la detección no puede ser identificada y desactivada como sí puede hacerse con un agente del lado del navegador. Cuando se dispara una detección, cside conserva el payload malicioso exacto en un archivo inmutable, dando a tu equipo de respuesta a incidentes y a un QSA el código de ataque real en lugar de una alerta de comportamiento. El motor de cside también aprende lo que se supone que debe hacer cada script y marca las desviaciones automáticamente, en lugar de requerir las reglas de permiso por script que un modelo de sandbox necesita mantener actualizadas a medida que evoluciona tu checkout.
Jscrambler
Jscrambler empezó en la ofuscación de JavaScript y más tarde añadió un producto de integridad de páginas web. Su fortaleza principal es proteger el JavaScript propio, transformando el código propietario para que sea más difícil de aplicar ingeniería inversa, con "bloqueos de código" que restringen dónde y cuándo se ejecuta el código. Para la detección de amenazas del lado del cliente usa un enfoque basado en trampas: inyecta objetos señuelo y código de monitorización en tus páginas y espera a que un script malicioso interactúe con esas trampas.
Para Magecart, la detección basada en trampas tiene la misma debilidad central que cualquier modelo solo de navegador: no sabe lo que no detectó. Un skimmer que evita los objetos señuelo o bloquea los endpoints de callback pasa desapercibido, y como el código de monitorización se ejecuta en el navegador, un atacante sofisticado puede encontrarlo y eludirlo. Jscrambler no rastrea en absoluto el contenido de los scripts, así que tras un ataque muestreado o condicional a menudo no queda ningún payload malicioso que analizar, lo que dificulta el análisis forense y la evidencia PCI. La ofuscación tampoco cierra la brecha, ya que el navegador sigue ejecutando llamadas a API observables y la desofuscación asistida por LLM cada vez lee mejor la intención.
cside se construyó para la seguridad del lado del cliente y para PCI DSS 6.4.3 y 11.6.1 desde el principio. Monitoriza el comportamiento de los scripts en sesiones de usuarios reales sin muestreo, descarga cada script para un análisis profundo en su propia infraestructura (usando LLMs que ejecuta él mismo, así que ningún dato de script sale hacia un proveedor de IA externo) y archiva el código de ataque en bruto para revisión de QSA. En la categoría independiente de Seguridad del Lado del Cliente de los Globee Cybersecurity Awards 2026, cside obtuvo el Oro (Mejor de la Categoría) y Jscrambler obtuvo la Plata.
DomDog
DomDog está diseñado específicamente para los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1, con información de producto totalmente pública y un precio que empieza en $999 al año, similar a cside. La configuración es un único script añadido a la etiqueta del header. Funciona como un agente JavaScript que recopila datos, muestra los scripts en un panel y pide al usuario revisarlos y añadirlos a una lista de permitidos o bloqueados, respaldado por una Content Security Policy secundaria.
Para Magecart en concreto, ese diseño de agente más CSP deja una ventana de skimming real. Como DomDog no se sitúa en el flujo de entrega de scripts, un script XSS almacenado que se vuelve malicioso puede activarse sin ser detectado, y su CSP confía en orígenes preaprobados en lugar de en su contenido, así que un intercambio de contenido del mismo origen, exactamente el patrón Polyfill donde polyfill[.]io seguía siendo el dominio pero el payload cambiaba, se cuela. DomDog monitoriza los cambios de comportamiento pero no analiza ni archiva payloads, así que la detección ocurre después de la entrega y no hay código de ataque que entregar a un auditor. cside no pudo encontrar ninguna certificación SOC 2 o PCI DSS publicada para DomDog.
cside realiza el análisis de payloads en su propia infraestructura, descargando los scripts del lado del servidor e identificando la intención maliciosa a nivel de código, lo que detecta skimmers dirigidos que solo se activan bajo condiciones específicas como ciertas geografías, ventanas de tiempo o tipos de dispositivo. Mantiene archivos inmutables de cada payload de script con el historial de versiones completo, así que una auditoría obtiene el código de ataque real y una cronología completa en lugar de un registro de cambios de comportamiento, y su cobertura se extiende más allá de los estándares de tarjetas de pago a HIPAA, GDPR y CPRA.
Cómo elegir software de protección contra Magecart
Ignora los nombres de los proveedores y puntúa cada opción de la tabla comparativa frente a estos criterios. Magecart es una amenaza en tiempo de ejecución y dentro de la sesión, así que una herramienta tiene que cumplirlos todos, no la mayoría, para cerrar realmente la brecha:
- Monitorización de scripts en tiempo real en el 100% de las sesiones de usuarios reales, sin muestreo. Un escáner remoto periódico o un crawler desde infraestructura de nube puede recibir un script limpio mientras se roba a los compradores reales. La cobertura tiene que situarse en el tráfico real de usuarios, no en una visita programada.
- Detecta cambios de comportamiento en scripts ya aprobados. El vector Magecart más común es un script comprometido que ya estaba en tu lista de permitidos. Bloquear nuevos scripts no basta; la herramienta debe marcar cuándo un script permitido empieza a leer campos de formulario o a llamar a endpoints que nunca antes había tocado.
- Detección que el atacante no puede ver ni desactivar. Si la monitorización se ejecuta por completo en el navegador, un actor malicioso puede estudiar los disparadores y diseñar en torno a ellos, o interceptar la alerta antes de que salga de la página. El análisis en la propia infraestructura del proveedor elimina esa superficie de ataque.
- Archivado de payloads desofuscados para análisis forense. Las alertas de comportamiento por sí solas no prueban lo que ocurrió. Quieres un archivo inmutable del código de ataque real (desofuscado), porque los skimmers suelen ser muestreados o condicionales y de otro modo no dejan nada atrás.
- Evidencia validada por QSA para PCI DSS 6.4.3 y 11.6.1. Ambos requisitos pasaron a ser obligatorios el 2025-03-31. Los informes autodescritos aún pueden requerir validación independiente en el momento de la evaluación, así que exige validación QSA independiente, no una casilla marcada.
- Un nivel gratuito para probarlo antes de firmar. Deberías poder verificar la detección en tus propias páginas de pago antes de comprometer presupuesto.
Puntúa cada herramienta con honestidad frente a esta lista. Solo una fila de la tabla anterior cumple todos los criterios.
Content Security Policy sola
Una CSP es un control gratuito y nativo del navegador, y debería desplegarse en cada página de pago como base. No sustituye al software de monitorización en tiempo de ejecución.
Una CSP bien configurada con nonces o hashes en los scripts inline previene la mayoría de las inyecciones Magecart oportunistas. No monitoriza el comportamiento en tiempo de ejecución de los scripts aprobados, no alerta cuando un script aprobado cambia lo que hace, y no produce el registro de auditoría que exige PCI DSS 4.0.1 Requisito 11.6.1. Trata una CSP como el punto de partida, no como la solución completa.
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.
