Magecart No Es un Titular. Es Tu Mayor Riesgo Actual.
Magecart es una familia de ataques de web skimming que llevan activos desde 2015 y han comprometido millones de transacciones en todo el mundo. El mecanismo es simple y devastador: un atacante inyecta unas pocas líneas de JavaScript en tu página de checkout — a través de una dependencia comprometida, un tag manager mal configurado o un proveedor de terceros vulnerado — y ese script captura silenciosamente los datos de tarjeta de cada comprador, enviándolos a un servidor controlado por el atacante.
Lo que hace a Magecart tan peligroso no es su sofisticación técnica, sino su invisibilidad. El comprador completa su compra sin errores. El comerciante recibe el pedido con normalidad. La pasarela de pago procesa la transacción correctamente. No hay nada roto. El skimmer simplemente copia los datos en paralelo. Pueden pasar semanas o meses antes de que las primeras reclamaciones de fraude revelen el problema.
Los casos más conocidos ilustran la escala del daño. British Airways recibió una multa de 20 millones de libras del ICO tras un ataque Magecart que comprometió los datos de 380.000 transacciones. Ticketmaster sufrió una brecha similar a través de un chatbot de terceros inyectado en su página de pago. En ambos casos, el código malicioso residía en el navegador del comprador, fuera del alcance de firewalls y WAFs tradicionales que solo inspeccionan tráfico servidor-a-servidor.
PCI-DSS 4.0: El Cambio que Tu E-commerce No Puede Ignorar
El 31 de marzo de 2025 entraron en vigor los requisitos más importantes de PCI-DSS 4.0 para comercios online. Por primera vez, el estándar exige control explícito sobre el JavaScript que se ejecuta en el navegador del comprador, no solo en tus servidores.
Dos requisitos cambian fundamentalmente cómo los e-commerce deben gestionar la seguridad del lado del cliente:
Requisito 6.4.3 exige que mantengas un inventario documentado y actualizado de todos los scripts que se ejecutan en tus páginas de pago. Cada script debe estar justificado (por qué está ahí), autorizado (quién lo aprobó) y verificado en su integridad (que no haya sido modificado). Esto incluye tu propio JavaScript, el SDK de tu pasarela, los pixels de seguimiento, el tag manager, los chatbots y cualquier otra dependencia que cargue en el contexto del checkout.
Requisito 11.6.1 exige un mecanismo de detección de cambios para las cabeceras HTTP y el contenido de las páginas de pago. Si alguien modifica un script, añade uno nuevo o altera las cabeceras de seguridad de tu página de checkout, debes detectarlo y responder.
La realidad es que la mayoría de los e-commerce no tienen visibilidad sobre qué JavaScript se ejecuta en su checkout. Marketing añade pixels de conversión. El equipo de producto integra un chatbot. Una agencia externa inyecta un script de personalización a través del tag manager. Cada uno de estos es un vector potencial de ataque y, desde marzo de 2025, cada uno debe estar inventariado y monitorizado.
Vulnerabbit automatiza este proceso. Nuestro módulo DAST navega tus páginas de pago, cataloga cada script que se ejecuta (origen, hash, comportamiento), y genera un inventario que puedes exportar para tu auditoría PCI-DSS. Si un script cambia, desaparece o aparece uno nuevo, recibes una alerta. No es un escaneo puntual: es monitorización continua de la integridad de tu checkout.
- → Marketing añade pixel vía GTM sin avisar a IT
- → Agencia inyecta script de A/B testing en checkout
- → Nadie sabe qué scripts corren en la página de pago
- → Incumplimiento PCI-DSS 4.0 desde el día uno
- → Inventario automático de scripts en páginas de pago
- → Hash de integridad verificado en cada escaneo
- → Alerta inmediata si aparece un script no autorizado
- → Reporte exportable para auditoría PCI-DSS
Los Subdominios que Marketing Olvidó, los Atacantes No
Cada campaña comercial genera activos digitales: un microsite para Black Friday, una landing de influencer, un subdominio de staging que la agencia necesitó para la demo del rediseño. Cuando la campaña termina, el presupuesto se cierra. Pero el subdominio sigue ahí, apuntando a un servidor que ya nadie mantiene.
La superficie de ataque de un e-commerce no es solo su tienda principal. Es la acumulación de todas las decisiones técnicas rápidas que se tomaron para lanzar campañas a tiempo. Un blackfriday.tienda.com que corría un WordPress con plugins de formulario. Un staging.tienda.com que tenía un volcado de la base de datos de producción para pruebas. Un old.tienda.com que apunta a un hosting que dejaste de pagar y ahora otro cliente ocupa esa IP.
Los atacantes lo saben y lo explotan de tres formas. Primero, phishing con legitimidad: un subdominio real de tu marca (ofertas.tutienda.com) es mucho más convincente que un dominio aleatorio para una campaña de phishing contra tus clientes. Segundo, SEO spam: atacantes inyectan contenido de farmacia o gambling en subdominios olvidados, penalizando tu dominio principal en buscadores. Tercero, pivoting: un subdominio con credenciales por defecto o software sin parchear puede ser la puerta de entrada lateral hacia tu infraestructura principal.
El caso más peligroso es el dangling CNAME: un registro DNS que apunta a un servicio cloud que ya no existe (un bucket de S3 eliminado, una instancia de Heroku cerrada, un Azure Blob desaprovisionado). Un atacante puede reclamar ese recurso y servir contenido arbitrario bajo tu dominio, con tu certificado SSL válido.
Tu Cloud Tiene los Datos de Tus Clientes. ¿Quién Vigila la Configuración?
La tienda es la fachada. Detrás hay bases de datos con millones de registros de clientes, buckets con imágenes de producto y backups, CDNs que sirven activos estáticos, y pipelines de procesamiento de pedidos. Una mala configuración en cualquiera de estos componentes puede exponer datos sin que nadie toque tu aplicación web.
Los errores de configuración cloud son la causa silenciosa de muchas brechas en e-commerce. No son ataques sofisticados: son buckets de S3 con acceso público que contienen exports de la base de datos de clientes. Son snapshots de bases de datos sin cifrar compartidos entre cuentas para que el equipo de analytics pueda trabajar. Son CDNs que exponen rutas de administración porque nadie configuró reglas de origen correctamente. Son logs de transacciones almacenados sin política de retención que acumulan años de datos de tarjeta parciales.
El problema es que estos errores no son visibles desde fuera. Un escaneo DAST ve la tienda; un análisis ASM ve los dominios. Pero la capa cloud requiere inspección interna. CSPM (Cloud Security Posture Management) conecta con tu cuenta de AWS, GCP o Azure y audita la configuración contra buenas prácticas y marcos regulatorios.
Para un e-commerce, CSPM responde preguntas concretas: ¿están cifradas en reposo las bases de datos que contienen PII de clientes? ¿Los backups tienen permisos de acceso restrictivos o cualquier desarrollador con credenciales de staging puede descargarlos? ¿El CDN está configurado para no servir archivos de configuración o directorios internos? ¿Los logs de la pasarela de pago se retienen solo el tiempo necesario y se almacenan cifrados?