La mejor herramienta de detección de Magecart para PCI DSS es la que produce salida que un QSA aceptará como evidencia. La detección que solo bloquea o solo alerta no basta. Los requisitos 6.4.3 y 11.6.1 te piden probar cuatro cosas en el tiempo: que conoces cada script en tu página de pago, que cada uno está autorizado, que recibes alerta cuando uno cambia sin aprobación y que puedes mostrar el historial.
Eso redefine la compra. Busca un sistema de registro que convierta un evento de navegador en una entrada de inventario, una decisión de autorización, una alerta de manipulación y un log de cambios retenido, no solo la alarma de skimmer más ruidosa. La mayoría del marketing de "detección de Magecart" habla de la captura. La auditoría pide el rastro documental detrás de esa captura.
Este artículo evalúa herramientas de detección desde esa lente de evidencia PCI. No clasifica vendors por nombre ni cita especificaciones. Explica qué artefacto de evidencia produce cada categoría de capacidad, qué hueco deja cada una y qué exigir en una prueba. PCI DSS 4.0.1 hizo obligatorios 6.4.3 y 11.6.1 el 2025-03-31, así que la pregunta de evidencia está viva ahora, no en la próxima renovación. Si tu stack ya cubre las amenazas conocidas como maliciosas, el hueco suele ser la documentación, y por eso la prevención de Magecart y la evidencia PCI son ya el mismo trabajo.
¿Qué evidencia quiere realmente un QSA de la detección de Magecart?
Mapea el texto del requisito al artefacto que tu herramienta debe producir. Estas son las cosas que un evaluador abre durante una revisión de 6.4.3/11.6.1.
| Artefacto de evidencia PCI | Requisito que responde | Qué aspecto tiene "bien" |
|---|---|---|
| Inventario de scripts | 6.4.3 (saber qué se ejecuta) | Cada script en la página de pago, incluidos scripts dinámicamente inyectados y de CDN de terceros, capturado como lo ve el navegador |
| Registro de autorización | 6.4.3 (justificar cada script) | Una justificación y estado de aprobación por script, con quién decidió y cuándo |
| Alerta de integridad / manipulación | 11.6.1 (detectar cambios) | Alerta sobre cambio no autorizado en contenido de scripts y cabeceras HTTP de la página de pago, con diff |
| Historial de cambios | 6.4.3 + 11.6.1 (probar en el tiempo) | Log duradero y fechado de cada alta, cambio y baja de script, más la resolución de cada alerta |
La trampa es tratar la detección de Magecart como una función de seguridad y PCI como una casilla separada. Son el mismo control. Si la herramienta atrapa un skimmer pero no puede mostrar al assessor la entrada de inventario a la que pertenecía ese script, el estado de autorización que violó y el registro fechado de la alerta y su cierre, atrapaste el ataque y aun así fallaste la auditoría en documentación.
Por qué una comparación de firmas de malware falla la pregunta PCI
La mayoría de listas de "mejores herramientas de detección" comparan cobertura de amenazas: firmas conocidas, blocklists, feeds de dominios maliciosos. Eso importa para bloquear. No satisface 6.4.3 ni 11.6.1.
Magecart de cadena de suministro llega mediante un script en el que ya confías. El CDN del vendor sirve una versión nueva, el origen está en tu allowlist y el hash cambia por una razón que parece legítima. Un motor de firmas no ve nada porque el payload es nuevo y la fuente está permitida. El control PCI está diseñado justo para esto: 6.4.3 te obliga a inventariar y autorizar ese script de antemano, y 11.6.1 te obliga a alertar cuando su contenido cambia sin aprobación. La evidencia, no la firma, es lo que demuestra que habrías detectado el intercambio.
Evalúa la detección por si produce el registro de autorización y cambio, no solo por si reconoce los skimmers conocidos de hoy.
Cómo evaluar detección de Magecart por categoría de capacidad
Las herramientas de detección caen en unas pocas categorías arquitectónicas. Cada una produce evidencia distinta y deja un hueco distinto. Puntúalas por lo que entregan al evaluador.
| Categoría de capacidad | Inventario | Registro de autorización | Alerta de manipulación (contenido + cabeceras) | Historial de cambios | Hueco principal de evidencia |
|---|---|---|---|---|---|
| Escáner externo (rastrea desde IPs cloud) | Parcial, ve solo lo que carga su crawler | Normalmente manual, añadido encima | Periódica, puede perder cambios entre escaneos | Basado en snapshots | Pierde scripts por sesión, por geografía y post-interacción |
| CSP + SRI (política aplicada por navegador) | No, constriñe en lugar de enumerar | No | Solo política de cabecera; SRI se rompe en scripts dinámicos | Informes de violación, no log de auditoría | Genera control, no inventario ni papeleo de autorización |
| Visibilidad de scripts en red/WAF | Parcial, lo que cruza el edge | No | Cabeceras y bloqueo de conocidos maliciosos | Logs de edge, no historial por script | Sin estado de autorización por script para el QSA |
| Monitorización runtime en navegador (agente en página) | Sí, captura scripts como los ejecuta el navegador | Sí, cuando la plataforma modela estado de aprobación | Sí, cambio de contenido y cabecera, con diff | Sí, log duradero y fechado por script | Requiere una etiqueta en la página de pago |
Lee la tabla como checklist de evidencia, no como concurso de popularidad. Un escáner es rápido de desplegar y útil para una línea base, pero un skimmer que solo se activa para compradores reales en un país puede servir una página limpia a la IP del crawler. CSP y SRI son controles reales que el PCI SSC nombra como mecanismos válidos, pero producen política e informes de violación, no los inventarios y registros de autorización que exige 6.4.3; además, los hashes de SRI se rompen con los scripts dinámicos de los que dependen muchos checkouts. Esa misma fragilidad es una de las razones por las que la Content Security Policy no funciona como respuesta PCI por sí sola. La monitorización runtime en navegador es la única categoría que produce los cuatro artefactos por sí misma, porque observa el script como lo hace el navegador de la víctima.
Un plan de compra que prueba evidencia, no funciones
No dejes que una demo termine en "mira, atrapó el script malo". Haz que la herramienta demuestre el rastro documental.
- Levanta una copia de staging de una página de pago real y conecta la herramienta.
- Publica un cambio benigno en un script, como añadir un comentario o subir una versión, y confirma que la herramienta lo marca con diff antes/después, página afectada y marca de tiempo.
- Modifica una cabecera HTTP de la página de pago y confirma que se activa detección de cambio de cabecera de 11.6.1, no solo detección de contenido de script.
- Registra una decisión de autorización (aprueba un script, rechaza el cambio) y confirma que ese estado queda almacenado, atribuido y fechado.
- Añade un script que solo carga para una sesión o geografía específica y comprueba si el inventario de la herramienta lo captura. Aquí falla la cobertura de escáneres externos, y es gran parte de por qué los crawlers no pueden ayudar con el cumplimiento PCI por sí solos.
- Exporta el inventario, los registros de autorización y el log de cambios. Lee la exportación como lo hará el evaluador. Si son capturas de pantalla o un feed de alertas sin etiquetas, no es evidencia.
Si una herramienta supera los pasos 2 a 6, produce documentación 6.4.3/11.6.1 lista para auditoría. Si se detiene en el paso 2, compraste monitorización, no cumplimiento.
Dónde encaja cside en el modelo de evidencia
cside es una plataforma de client-side security construida para la categoría de monitorización runtime en navegador, y específicamente para la evidencia que abre un QSA. No pasa tráfico por proxy. Una etiqueta en la página de pago captura scripts como los ejecuta el navegador real, lo que cierra el hueco de escáneres en orientación por sesión y geografía.
Para 6.4.3, PCI Shield mantiene un inventario vivo de cada script de la página de pago, incluidos scripts dinámicamente inyectados y de CDN de terceros, con estado de autorización por script. Para 11.6.1, alerta sobre cambios no autorizados en contenido de scripts y cabeceras HTTP de la página de pago, con un diff que muestra exactamente qué cambió. Cada alta, cambio, baja y resolución de alerta queda en un log de cambios fechado que puedes exportar. cside pasó una evaluación QSA independiente de VikingCloud para 6.4.3 y 11.6.1, así que el modelo de evidencia fue evaluado, no solo afirmado. Más allá del requisito, la plataforma añade monitorización de comportamiento de navegador y detección de bots/agentes IA, de modo que la misma instrumentación que produce tu registro PCI también aflora las anomalías de comportamiento que crea un skimmer nuevo.
A fecha de 2026-06-18, trata esto como una guía operativa, no como asesoramiento legal. Confirma el texto exacto de los controles y qué aceptará tu evaluador como evidencia con tu QSA, asesor jurídico o responsable de riesgos.
