TL;DR: cumplimiento PCI en Magento
- Magento no se encarga de los requisitos 6.4.3 y 11.6.1 por ti. Cada script de tu página de pago necesita una entrada en el inventario, una justificación de negocio y monitorización continua de integridad.
- Los escaneos ASV cubren el requisito 11.3.2. No detectan amenazas de JavaScript en las páginas de pago. Los comercios que tratan el escaneo ASV como su control de seguridad principal se están dejando fuera lo que PCI DSS 4.0.1 exige de verdad para el riesgo del lado del cliente.
- El vector de ataque más habitual contra Magento en 2024 y 2025 es la exfiltración por WebSocket a través de extensiones comprometidas. Esquiva la CSP, esquiva la monitorización de red y solo es visible para una herramienta que observa el runtime del navegador directamente.
Qué es el cumplimiento PCI en Magento
Las tiendas Magento no cumplen PCI DSS de forma automática. Magento Commerce Cloud cubre parte de los controles a nivel de infraestructura, pero el comercio sigue siendo responsable de proteger sus páginas de pago frente a ataques del lado del cliente. Los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 obligan a inventariar, autorizar y monitorizar la integridad de todos los scripts de las páginas de pago, controles que Magento no ofrece de forma nativa, uses la extensión de pago que uses.
El malentendido habitual: los comercios asumen que usar una extensión de pago certificada, o delegar el procesamiento del pago a una página de pago alojada, ya satisface PCI DSS. Reduce el alcance, pero no lo elimina. Cualquier página de Magento que cargue funcionalidad de checkout, o que entre en el entorno de datos del titular de la tarjeta por cargar scripts de terceros, está dentro del alcance de los requisitos 6.4.3 y 11.6.1.
Una página de pago típica de Magento carga píxeles de seguimiento, etiquetas de analítica, herramientas de test A/B, scripts de afiliación, widgets de chat y librerías de pago. Cada uno está dentro del alcance. Cada uno necesita una entrada de inventario con su justificación de negocio. Cada uno debe monitorizarse por cambios de integridad entre evaluaciones.
Requisitos de PCI DSS que los comercios Magento suelen incumplir
Requisito 6.4.3: inventario y autorización de scripts. Hay que inventariar todos los scripts que se cargan en una página de pago. El inventario debe documentar la justificación de negocio de cada script, confirmar que está autorizado e incluir un método para verificar que su integridad no ha cambiado. Una lista estática en una hoja de cálculo no cumple este requisito: el inventario tiene que reflejar el estado real de la página de pago, porque los scripts cambian.
Requisito 11.6.1: detección de manipulación en la página de pago. El comercio debe disponer de un mecanismo que detecte cambios no autorizados en las cabeceras HTTP y en el contenido de la página de pago, y que avise al equipo responsable dentro de un plazo definido. Una revisión manual periódica no cumple este requisito. El mecanismo tiene que ser capaz de detectar la aparición de un script nuevo, el cambio de un script existente o la modificación de una cabecera HTTP entre ciclos de revisión.
Ambos requisitos pasaron a ser obligatorios el 2025-03-31 y ya se evalúan de forma activa. Si tu tienda Magento no tiene una herramienta que genere evidencia continua para estos requisitos, tu próxima evaluación PCI DSS está en riesgo.
Qué es un Approved Scanning Vendor (ASV)
Un Approved Scanning Vendor (ASV) es una empresa certificada por el PCI SSC para realizar escaneos externos de vulnerabilidades, tal y como exige el requisito 11.3.2 de PCI DSS. Los escaneos ASV sondean los componentes de red expuestos a internet en busca de vulnerabilidades conocidas. No detectan amenazas de JavaScript del lado del cliente en las páginas de pago, ni scripts de terceros no autorizados, ni las anomalías de comportamiento que cubren los requisitos 6.4.3 y 11.6.1. Pasar un escaneo ASV no significa que tu checkout de Magento esté protegido frente a ataques tipo Magecart.
Lo que sí hacen los escaneos ASV: sondear tus direcciones IP y dominios públicos en busca de CVE conocidos, puertos abiertos, servicios mal configurados y vulnerabilidades a nivel de red. Un informe ASV limpio confirma que el perímetro de tus servidores no tiene vulnerabilidades explotables conocidas detectables desde fuera.
Lo que no hacen: analizar el JavaScript que se ejecuta en tus páginas de pago, detectar scripts que no estaban presentes en el escaneo anterior, verificar que los scripts de terceros no se han modificado desde la última aprobación, ni observar qué datos envían los scripts a endpoints externos durante una sesión real de un visitante.
Esta carencia no es una crítica al escaneo ASV. Es una descripción de para qué sirve la herramienta. Los controles de cumplimiento que cubren las amenazas de JavaScript del lado del cliente son el 6.4.3 y el 11.6.1, no el 11.3.2. Una tienda Magento puede pasar todos los escaneos ASV trimestrales mientras ejecuta un script comprometido que exfiltra datos de titulares de tarjeta en tiempo real.
El vector de ataque contra Magento que los escaneos ASV no pueden ver
cside sigue las TTP activas contra comercios Magento. El patrón de ataque más sofisticado observado en 2024 y 2025 usa conexiones WebSocket para exfiltrar datos en lugar de peticiones HTTP estándar.
Por qué los WebSockets esquivan las defensas tradicionales:
Los ataques Magecart clásicos exfiltran datos mediante peticiones HTTP POST a dominios controlados por el atacante. Las directivas connect-src de la CSP pueden bloquearlas si el dominio del atacante no está en la lista de permitidos. Las herramientas de monitorización de red pueden ver el POST saliente y marcarlo.
Las conexiones WebSocket con el protocolo wss:// son distintas. Muchas configuraciones de CSP no restringen los orígenes WebSocket de forma separada de los orígenes HTTP. Las herramientas de monitorización centradas en tráfico HTTP pueden no ver las conexiones wss:// en absoluto. El atacante mantiene un canal bidireccional persistente con el navegador de la víctima, puede modificar los scripts inyectados sobre la marcha sin provocar una nueva carga de página y puede exfiltrar datos de tarjeta de forma continua en lugar de en peticiones POST sueltas.
El vector de acceso: CosmicSting (CVE-2024-34102), divulgado en junio de 2024, permitía a atacantes no autenticados leer ficheros del servidor en instalaciones de Adobe Commerce y Magento, incluidos ficheros de configuración con credenciales de base de datos y claves de API. Con esas credenciales en la mano, los atacantes inyectaron el skimmer basado en WebSocket directamente en las páginas de pago de Magento. El parche de CVE-2024-34102 cierra el vector de acceso inicial. No elimina los scripts ya inyectados. Los comercios que parchearon el CVE pero no auditaron los scripts de sus páginas de pago en busca de restos posteriores a la explotación pueden seguir sirviendo el skimmer.
La única capa de detección que atrapa este ataque es la que instrumenta el runtime del navegador directamente: observar qué scripts se ejecutan en sesiones reales de visitantes, qué llamadas a API hacen y adónde envían datos, en tiempo real y en cada sesión.
Cómo protege cside los checkouts de Magento
cside se despliega como un único snippet de JavaScript de origen propio en tus páginas de pago de Magento. Monitoriza el runtime del navegador en cada sesión real de visitante y genera evidencia continua para los requisitos 6.4.3 y 11.6.1.
Para el requisito 6.4.3: cside mantiene un inventario vivo de todos los scripts que se cargan en cada página monitorizada, con el campo de justificación de negocio, el estado de autorización y el hash de integridad en cada carga. Cuando aparece un script nuevo, o cambia uno existente, el inventario se actualiza y salta una alerta.
Para el requisito 11.6.1: cside detecta cambios en los scripts y en las cabeceras HTTP de las páginas de pago en tiempo real, en sesiones reales de visitantes, y genera un rastro de evidencia con marca de tiempo que los QSA aceptan para el requisito.
Para los ataques por WebSocket: como cside instrumenta el runtime de JavaScript directamente, observa las conexiones WebSocket que abren los scripts de la página, aparezcan o no en los registros de tráfico HTTP y estén o no cubiertas por la CSP.
Consulta cómo cumplir con PCI 6.4.3 y 11.6.1 para ver el recorrido detallado de implementación.
