TL;DR: Ataques Magecart
- Qué es un ataque Magecart: Un ataque Magecart es un ataque de web skimming basado en el navegador en el que se inyecta JavaScript malicioso en un sitio web con el objetivo de robar datos de tarjetas de pago o entradas de formularios sensibles directamente desde el navegador del usuario durante el proceso de pago o inicio de sesión.
- Por qué los ataques Magecart son difíciles de detectar: Magecart opera completamente en el navegador, por lo que las defensas tradicionales como WAFs, SIEMs y la monitorización de transacciones no detectan nada inusual mientras los pagos legítimos siguen procesándose con normalidad.
- Cómo prevenir los ataques Magecart: Una prevención eficaz requiere minimizar los scripts en las páginas de pago, gestionar y monitorizar el JavaScript de terceros, aplicar controles del navegador como CSP y SRI, y desplegar una herramienta de monitorización continua del lado del cliente como cside.
"Recientemente me notificaron de una brecha de datos en tu tienda y mi tarjeta de crédito ha sido utilizada de forma fraudulenta."
Esto es una pesadilla para el equipo de soporte. Y no solo eso: los equipos de fraude y finanzas también están recibiendo alertas de los emisores de tarjetas y preguntas de los proveedores de pago.
Magecart no consiste en falsificar páginas de inicio de sesión o de pago. Se trata del abuso de tus páginas reales de inicio de sesión y de pago, en las que los clientes confían.
Eso es Magecart: lo que ocurre cuando tu inicio de sesión y tu proceso de pago se convierten en el eslabón más débil de tus controles de seguridad. Aunque tus servidores, WAF y controles PCI sean sólidos, unas pocas líneas de JavaScript malicioso en el navegador pueden capturar datos de tarjetas e información personal durante semanas antes de que nadie lo note.
Esta guía explica qué es Magecart, cómo funciona, por qué es difícil de detectar y qué herramientas existen para la prevención de Magecart.
¿Qué es un ataque Magecart?
Un ataque Magecart es un ataque de web skimming basado en el navegador. Se inyecta JavaScript malicioso en un sitio de comercio electrónico con un único propósito: robar datos de tarjetas de pago.
Es algo que no le deseas a ti mismo ni a tus clientes. Es una pesadilla para las tiendas online porque abusa de la confianza de tus clientes. Causa un daño enorme al negocio digital: pérdidas económicas, contracargos, multas regulatorias y un grave daño reputacional.
Tu WAF y tu stack de seguridad del lado del servidor no verán nada de esto. El ataque vive completamente en el navegador del usuario, en un entorno de código que tu monitorización de backend nunca toca. Incluso otros controles relacionados con PCI DSS, como el cifrado o la tokenización, no sirven de nada si el atacante roba los datos de la tarjeta antes de que esas defensas entren en juego. Las transacciones en tu lado siguen procesándose como si nada fuera mal. Desde tu perspectiva, todo parece un día normal de negocio. Pero mientras tanto, los datos se exfiltran silenciosamente desde el navegador de tu cliente hacia los servidores del atacante.
Magecart es un tipo de web skimming
Magecart es una forma de web skimming (o e-skimming). El web skimming es la versión online del skimming de tarjetas de crédito en cajeros automáticos: las pulsaciones de teclas o las entradas son copiadas por dispositivos ocultos y posteriormente utilizadas para gastar dinero en otro lugar. Cuando los atacantes añaden su JavaScript malicioso a una tienda online, se abren muchas oportunidades para ellos. Pueden ver lo que un usuario escribe en los formularios de pago o de inicio de sesión y exfiltrar secretamente estos datos a sus propios sistemas.
Cómo ha evolucionado el término "Magecart"
Alrededor de 2015-2016, los investigadores de seguridad comenzaron a reportar que las tiendas online basadas en Magento estaban siendo objetivo de ataques de skimming de tarjetas online. Típicamente, se inyectaba JavaScript en las páginas de pago para robar y exfiltrar datos de pago e información personal. De ahí: 'Magecart' — 'Mage' de Magento y 'cart', abreviatura de carrito de compra.
Con el tiempo, los ataques Magecart se extendieron a otras plataformas y configuraciones de comercio electrónico personalizadas. Cualquier plataforma con JavaScript del lado del cliente y scripts de terceros era vulnerable, no solo Magento.
Del skimming de tarjetas en Magento a los ataques de estilo Magecart en todas partes
Magecart evolucionó hasta convertirse en un estilo de ataque: una etiqueta para el skimming digital, el formjacking, el e-skimming, el skimming de tarjetas online, y se ha convertido en una amenaza importante para las plataformas de venta minorista online.
Magecart es menos un apodo para un grupo específico y más una etiqueta paraguas para un ecosistema de grupos y técnicas de skimming digital. En términos generales, utilizan el mismo vector de ataque pero se apoyan en infraestructuras y herramientas diferentes.
Cómo funcionan los ataques Magecart
La idea parece sencilla: copiar los datos del formulario y exfiltrarlos a un endpoint comprometido. ¿Qué tan difícil puede ser? En realidad, estos ataques son más sutiles y sofisticados. En todo momento, la tienda online debe comportarse con normalidad: sin errores, sin tiempos de espera.
Para que el skimming digital sea exitoso, ni tus sistemas de monitorización ni tus clientes deben notar nada fuera de lo ordinario.
Así es como se desarrolla un ataque Magecart típico en el navegador.
1. Inyección de JavaScript malicioso en el sitio
Primero, el atacante necesita una forma de ejecutar su propio JavaScript en el navegador del usuario, porque ahí es donde tiene lugar el ataque. Busca vulnerabilidades como plugins o componentes CMS desactualizados o mal configurados, o scripts de terceros descuidados como un plugin, archivos CDN, gestores de etiquetas, etc.
Este punto débil se convierte en el vector de ataque: el atacante añade un par de líneas de su JavaScript malicioso a un archivo de producción existente o a un script de terceros. El cambio es mínimo, a menudo mezclado con código legítimo, por lo que nada llama la atención durante una revisión de seguridad.
2. Lectura de datos de pago y formularios
Una vez hecho esto, el JavaScript malicioso accede al DOM y lee los datos que el usuario introdujo en el formulario. Que JavaScript acceda y modifique el DOM es un comportamiento normal en el desarrollo web moderno. Es la forma en que JavaScript hace las páginas dinámicas sin recargar el documento HTML completo. Muchos frameworks como React o Svelte se basan en que JavaScript puede manipular el DOM.
El skimmer digital ahora se centra en campos específicos del formulario de pago o de inicio de sesión: número de tarjeta, fecha de vencimiento, CVV, nombre, dirección, etc. Copia estos valores sin modificar el formulario ni el flujo del usuario de ninguna forma visible.
3. Exfiltración de los datos al servidor del atacante
Una vez capturados los datos, el siguiente paso es transferirlos de forma inadvertida a un servidor controlado por el atacante. La mayoría de las veces, el disparador de la exfiltración es que el usuario haga clic en el botón 'pagar'/'enviar'. En ese momento, el script ensambla el payload (en bruto o codificado) con los detalles de la tarjeta, la información personal y, a menudo, detalles de contexto como marcas de tiempo o URLs.
Las técnicas de exfiltración típicas incluyen fetch, XMLHttpRequest para código antiguo, solicitudes de imágenes ocultas y navigator.sendBeacon(). TLS/HTTPS no detendrá la exfiltración porque parece una solicitud https legítima, con un payload muy pequeño. Los atacantes suelen usar dominios que se parecen mucho a los nombres de host legítimos utilizados por tiendas online, CDNs o servicios de analítica para no levantar sospechas. Si la solicitud de exfiltración falla, el código simplemente captura el error y no se ejecuta. Pero la transacción legítima sí se completará.
4. Mantener la tienda en funcionamiento y el proceso de pedidos activo
Para que el ataque Magecart sea efectivo, las transacciones deben seguir fluyendo. El skimmer exfiltra una copia de los datos, pero el formulario de pago también se envía a tu backend y pasarela de pago. Los pedidos se crean, los pagos se autorizan y tus sistemas de fulfillment se ponen en marcha.
Cómo los atacantes obtienen acceso a los scripts web para los ataques Magecart
Los atacantes escanean en busca de puntos débiles en tu stack web: lugares donde los scripts pueden editarse y el código de skimming puede colarse. Para defender tu sitio y construir un modelo de amenazas eficaz, debes centrarte en algunos vectores de entrada comunes para los ataques Magecart.
1. Magecart a través de plugins, CMS o código de la plataforma de comercio electrónico
Tu propio CMS o plataforma de comercio electrónico es una superficie de ataque directa. Plataformas como Magento, WooCommerce, aplicaciones de Shopify y código de checkout personalizado requieren un escrutinio regular. Los puntos débiles típicos son los plugins y extensiones desactualizados, o las ediciones inseguras de plantillas o archivos JavaScript. Las cuentas de administrador necesitan protección adicional: si un atacante puede iniciar sesión como administrador, los cambios en los scripts son sencillos.
Si tu tienda online está ejecutando un plugin de pago o seguimiento desactualizado en Magento o WooCommerce, el skimming digital está a un solo paso. Si los atacantes logran modificar los archivos del plugin o abusar de una cuenta de administrador, solo necesitan editar un único archivo JavaScript en la página de pago para añadir su skimmer.
2. Magecart a través de la cadena de suministro de código de terceros
Esto incluye cualquier entrada a través de <script src> o un gestor de etiquetas: bibliotecas CDN, herramientas de A/B testing o analítica para el equipo de marketing, widgets de chat/soporte para atención al cliente, etc. Estos scripts son gestionados y alojados por proveedores externos o inyectados a través de gestores de etiquetas que pueden ejecutar código en la mayoría de las páginas. Basta con un script de terceros comprometido o una cuenta de gestor de etiquetas abusada para distribuir código de skimmer a todos los sitios y páginas donde se usa ese código.
A veces una cuenta de Google Tag Manager (GTM) o un widget de chat externo tiene código que se carga en todo el sitio (incluidas las páginas de pago) aunque no tenga ninguna funcionalidad en esas páginas. Si GTM es tomado y se añade una etiqueta extra con código JavaScript de skimmer, cada formulario de pago en cada sitio que use el contenedor estará ejecutando código Magecart.
Por qué los ataques Magecart son difíciles de detectar
Ahora que hemos visto cómo funciona un ataque Magecart en el navegador, es justo preguntarse: ¿por qué las defensas tradicionales no lo detectan? Tenemos reglas WAF, dashboards SIEM y controles PCI. Sin embargo, estas capas de seguridad siguen teniendo un punto ciego para los ataques del lado del cliente basados en el navegador, como Magecart.
1. WAF, SIEM y los datos de transacciones no detectan los ataques Magecart
La mayoría de las herramientas de seguridad web están diseñadas para proteger la actividad del lado del servidor o monitorizar la infraestructura de la empresa, no el navegador de los usuarios. Un WAF inspecciona el tráfico hacia tus aplicaciones, pero no ve lo que el navegador envía directamente a otros dominios. Un SIEM muestra los registros del servidor y la infraestructura, pero no registra las llamadas salientes adicionales del navegador hacia endpoints maliciosos.
Analizar los datos de transacciones en busca de fraude no revelará evidencia de un ataque Magecart porque el flujo de compra legítimo sigue completándose con normalidad. El skimmer copia los datos de la tarjeta en el navegador mientras el backend ve una transacción limpia y autorizada sin anomalías.
Los atacantes hábiles pueden interceptar valores sensibles a nivel del DOM antes de que lleguen a tus servidores, silenciando efectivamente tus sistemas de alertas.
2. La falta de visibilidad sobre los scripts de terceros aumenta el riesgo de Magecart
Tener visibilidad completa sobre los scripts de terceros es un enorme desafío. ¿Qué scripts se están ejecutando? ¿Tienen permiso para ejecutarse en un formulario de pago o en una página de inicio de sesión? ¿Quién hace seguimiento de su comportamiento y sus cambios a lo largo del tiempo? Son preguntas muy básicas con las que muchas organizaciones luchan cuando nadie es realmente responsable de la cadena de suministro del lado del cliente.
Los desarrolladores web tienen un control limitado sobre estos scripts, porque son gestionados y alojados por proveedores externos. Cuando cambia la propiedad o se despide personal, los scripts de terceros o las bibliotecas JavaScript pueden dejar de actualizarse, y una vulnerabilidad en cualquiera de esos scripts de terceros puede convertirse en un riesgo de seguridad.
Este es precisamente el vector de entrada que explotan los ataques Magecart. Comprometer un script o biblioteca de terceros ampliamente utilizado puede convertirlo en un ataque de cadena de suministro a gran escala que afecte a todos los sitios que lo usan.
3. Un problema del lado del cliente necesita una defensa del lado del cliente
Este es el problema central de Magecart: la mayoría de las empresas no tienen visibilidad real de lo que ocurre en el navegador. Los dashboards de seguridad del lado del servidor no muestran a qué dominios envía solicitudes el navegador durante el proceso de pago, incluso cuando se trata de llamadas de origen cruzado (CORS).
No alertan cuando aparece un nuevo dominio de destino en un formulario de pago. Y no envían una advertencia sobre una violación de la Content Security Policy (connect-src) cuando un script intenta exfiltrar datos a un endpoint inesperado.
4. El fraude solo se descubre más tarde, mucho más tarde
Uno de los aspectos más dañinos de un ataque Magecart es que raramente es detectado por la propia organización que fue vulnerada. En la mayoría de los casos, las primeras señales de alerta provienen de bancos, emisores de tarjetas o clientes. Para cuando estos informes externos salen a la luz, el skimmer ya ha recopilado un volumen significativo de datos de titulares de tarjetas.
Cómo prevenir los ataques Magecart
Los principios básicos de la prevención de Magecart son sencillos: mantén tu flujo de pago lo más limpio y minimalista posible, mantén el control de los scripts que se ejecutan en él y añade controles del lado del navegador con monitorización continua 24/7. Los siguientes pasos lógicos te ayudarán a implementar medidas de prevención para reducir tu exposición a Magecart.
1. Ejecuta solo los scripts necesarios en el inicio de sesión y el proceso de pago
En el inicio de sesión y el proceso de pago, cada script adicional añade riesgo. Estas páginas deben cargar solo lo básico de UX y lo estrictamente necesario para la autenticación y el pago. Sin dudarlo, elimina marketing, analítica, widgets de chat, etc. del inicio de sesión y del proceso de pago.
Preferiblemente, aísla el proceso de pago y usa una plantilla minimalista o incluso un subdominio separado con solo los inputs de terceros necesarios. Al hacerlo, limitas tu superficie de ataque y las oportunidades para que el código Magecart oculte sus rastros. Además, te resultará mucho más fácil limpiar si algo sale mal.
2. Usa cside para la gobernanza de scripts de terceros
Crea un inventario de scripts para tener una visión clara de qué scripts se ejecutan dónde y qué hacen realmente. Las páginas sensibles, incluidas las de inicio de sesión y pago, solo deben servir scripts de terceros que hayan sido aprobados con una justificación.
Por último, define un proceso de gestión de cambios para especificar quién tiene permiso para modificar scripts y contenedores del gestor de etiquetas. También puedes exigir vistas previas y aprobación antes de que los cambios entren en producción. En paralelo, aplica una gobernanza estricta de proveedores e incluye la seguridad de scripts y la gestión de incidentes como parte de los contratos y el proceso de incorporación con proveedores externos.
Una herramienta de gobernanza de scripts de terceros puede automatizar estos elementos de inmediato con un dashboard que asocia cada script a un proveedor y genera automáticamente descripciones de lo que hace cada script.
3. Usa controles del navegador: CSP y SRI
Una Content Security Policy (CSP) te ayuda a definir desde dónde se pueden cargar los scripts (script-src) y hacia dónde puede enviar datos el navegador (connect-src).
script-src debe restringirse a dominios de confianza y connect-src debe permitir solo los endpoints necesarios para el proceso de pago, en lugar de permitir cualquier destino.
Habilitar una CSP también ayuda a reportar violaciones de la política, especialmente en el inicio de sesión y el proceso de pago. Se revelarán intentos inesperados de inyección de scripts y exfiltración. Para bibliotecas de terceros estáticas, usa Subresource Integrity (SRI) para reforzar la integridad, pero trátalo como una capa más en tu defensa, no como la solución definitiva.
4. Usa cside para la monitorización de Magecart
Con Magecart, necesitas ojos en el navegador. La monitorización automatizada continua del lado del cliente, 24/7, revelará qué scripts se están ejecutando y los comportamientos sospechosos que señalan actividad de Magecart. Una herramienta de prevención de Magecart mapea todos los scripts de tu sitio y utiliza un motor asistido por IA para detectar señales de alerta a partir de una variedad de puntos de datos.
cside ayuda a los comerciantes a identificar y detener:
- Ataques a la cadena de suministro de JavaScript de terceros
- Scripts de terceros maliciosos o manipulados
- Scripts mal configurados que filtran datos sensibles
- Magecart, e-skimming, formjacking y skimmers relacionados
cside está validado para los requisitos del lado del cliente de PCI DSS 4.0.1 y es utilizado por equipos de cumplimiento para prevenir violaciones de GDPR, CCPA y otras normativas de privacidad causadas por scripts de terceros de riesgo.
Autoevaluación rápida de preparación ante Magecart
¿Estás preparado para defenderte de los ataques de estilo Magecart? Sí/No
- Nuestras páginas de pago e inicio de sesión solo cargan scripts cuyo propósito y comportamiento esperado conocemos.
- Tenemos una lista actualizada de todos los scripts, propios y de terceros, que se ejecutan en nuestra página de pago.
- El marketing, la analítica, las pruebas A/B y los widgets de chat están monitorizados para garantizar que no recopilan más datos de los necesarios.
- Los cambios en scripts de "confianza", como los contenedores del gestor de etiquetas…
- Verificamos la integridad de los scripts mediante una herramienta de seguridad del lado del cliente u otro mecanismo (como Sub Resource Integrity).
- Contamos con monitorización del lado del cliente que muestra a dónde se envían los datos recopilados por scripts de terceros.
- Tenemos un mecanismo para bloquear scripts que han sido identificados públicamente como comprometidos.
Los mayores ataques Magecart de la historia reciente
Nuestro informe de amenazas del lado del cliente de 2025 identificó más de 72.000 sitios web afectados por ataques del lado del cliente. Esos ataques siguen el mismo patrón que los mayores ataques Magecart de la historia reciente: unas pocas líneas de JavaScript malicioso comprometen a millones de usuarios antes de que nadie lo note. A continuación, un resumen rápido de los casos más destacados.
- Ticketmaster (2018) – Script de chatbot comprometidoLos atacantes inyectaron código de skimming en un chatbot de terceros alojado por Inbenta Technologies. Cada carga de página ejecutaba el script malicioso, exponiendo datos de pago e información personal de aproximadamente 9,4 millones de clientes durante cuatro meses. El incidente derivó en multas regulatorias y acuerdos en demandas colectivas.
- British Airways (2018) – 22 líneas de JavaScript maliciosoLos atacantes obtuvieron acceso usando credenciales de terceros comprometidas e insertaron solo 22 líneas de código de skimmer en una biblioteca utilizada en la página de pago de BA. Los datos fueron exfiltrados a un dominio similar al legítimo ("baways.com"), afectando a unos 400.000 clientes. BA se enfrentó a decenas de millones en multas por GDPR y años de litigios.
- Newegg (2019) – Script inyectado en la página de pagoLos atacantes obtuvieron acceso de escritura al servidor de pagos de Newegg y añadieron un pequeño skimmer al botón de pago. Cuando los clientes enviaban su pago, los datos de la tarjeta se enviaban a un dominio de analítica falso ("neweggstats.com"), comprometiendo números de tarjeta, CVVs e información personal durante más de un mes antes de ser detectado.
Preguntas frecuentes
¿Cómo sé si mi sitio tiene una infección de Magecart o e-skimming?
Los ataques Magecart son difíciles de detectar porque el proceso de pago sigue funcionando con normalidad y las herramientas del lado del servidor no detectan nada inusual. El único método fiable es la monitorización del lado del cliente con una herramienta como cside, que inspecciona los scripts que se ejecutan en el navegador y señala cambios sospechosos en el código o transferencias de datos salientes.
¿Pueden ocurrir ataques Magecart aunque use un procesador de pagos como Stripe o PayPal?
Sí. Si los campos de pago están alojados en tu propio sitio web (incluso cuando se usa un procesador de pagos externo), los scripts de terceros en tu página pueden seguir accediendo a lo que los usuarios escriben en esos campos. Si tu sitio redirige completamente a los clientes al dominio del proveedor de pagos (por ejemplo, checkout.stripe.com), Magecart no puede capturar los datos de la tarjeta allí. Sin embargo, otra información sensible de tu sitio, como credenciales de acceso, datos KYC o detalles de cuenta, puede seguir siendo extraída si hay scripts maliciosos presentes.
¿Puede ocurrir un ataque Magecart aunque tokenice o cifre los datos de la tarjeta de crédito?
Sí. La tokenización y el cifrado solo se producen después de que el cliente envía su pago, pero Magecart roba los datos mientras el usuario escribe. Incluso los flujos completamente tokenizados o cifrados siguen siendo vulnerables al skimming si hay scripts maliciosos ejecutándose en la página.
