Escrito por Mike Kutlu, cside. Las cifras de las páginas de pago proceden de la telemetría de navegador de producción de cside durante los 14 días que terminaron el 2026-07-22, en páginas dentro del alcance de PCI. El contexto de los ataques procede de informes públicos de incidentes y del análisis ya publicado por cside. La metodología y sus límites se detallan al final. Última revisión: julio de 2026.
Resumen rápido
- La página de pago mediana dentro del alcance de PCI carga 3 hosts de scripts de terceros distintos. La del percentil 90 carga 9 y la del percentil 99, 22.
- Alrededor del 48% de los scripts distintos de esas páginas los cargó otro script, no el HTML de la propia página, y en torno al 65% de las páginas arrastra una cadena de dependencias de al menos tres saltos.
- La superficie está fragmentada. Los 10 hosts principales cubren cerca del 41% de la presencia en las páginas monitorizadas, pero llegar al 80% exige unos 100, y la cola se extiende más allá de 9.000.
- El 91,6% de las páginas sirvió durante la ventana al menos un script que nunca había servido antes, con una mediana de 8 scripts nuevos por página.
- En junio de 2026, un proveedor externo comprometido metió un script drenador de carteras en el frontend de Polymarket y se llevó unos 3 millones de dólares de las carteras de los usuarios sin vulnerar ningún servidor ni tocar ningún contrato inteligente.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Resumen ejecutivo
Un comercio suele saber nombrar los terceros que añadió a su checkout. Lo que no sabe nombrar es el código que esos terceros traen consigo, y eso es lo que mide este informe.
En los checkouts dentro del alcance de PCI que monitoriza cside, la página mediana carga 3 hosts de scripts de terceros distintos, lo que suena manejable. Pero el 48% de los scripts distintos observados en esas páginas llegó a través de otro script, no del HTML de la propia página, y alrededor del 65% de las páginas arrastra una cadena de carga que se aleja al menos tres saltos de la página. El comercio eligió el primer salto; el resto lo eligió un proveedor, o el proveedor de un proveedor.
El requisito 6.4.3 de PCI DSS pide un inventario de cada script de la página de pago con una justificación de negocio para cada uno. En la mediana son unos 12 scripts, algo que un equipo de cumplimiento resuelve en una tarde. En el percentil 99 son unos 259, la mayoría cargados en cadena, y nadie dentro del comercio está en condiciones de justificar buena parte de esa lista.
El inventario tampoco se queda quieto. En dos semanas, el 91,6% de las páginas de pago monitorizadas sirvió al menos un script que no había servido antes, con una mediana de 8 scripts nuevos por página. El requisito 11.6.1 pide detección de cambios al menos cada siete días; ese es el volumen al que un control así tiene que seguir el ritmo.
En junio de 2026, un proveedor externo comprometido inyectó un drenador de carteras en el frontend de Polymarket y vació unos 3 millones de dólares de las carteras de los usuarios. No se vulneró nada del lado del servidor y los contratos quedaron intactos: todo el compromiso ocurrió en el navegador.
| Métrica (14 días finalizados el 2026-07-22) | Valor |
|---|---|
| Hosts de scripts de terceros por página (mediana / p90 / p99) | 3 / 9 / 22 |
| Scripts distintos por página (mediana / p90 / p99) | 12 / 46 / 259 |
| Scripts cargados por otro script | 48% |
| Páginas con una cadena de 3 o más saltos | 65% |
| Páginas que vieron un script nuevo en la ventana | 91,6% |
Todos los recuentos corresponden a terceros reales. Se excluyen los scripts propios (first-party) del comercio y la propia infraestructura de cside.
Qué carga realmente una página de pago
El inventario que exige el 6.4.3 empieza por elegir una unidad de medida, y las dos disponibles dan respuestas muy distintas.
Medida por hosts, la página mediana es modesta: 3 hosts de scripts de terceros distintos, 9 en el percentil 90 y 22 en el 99. Medidas por scripts individuales, esas mismas páginas llevan una mediana de 12, un percentil 90 de 46 y un percentil 99 en torno a 259. El recuento de hosts te dice con cuántas partes distintas habla la página; el recuento de scripts es lo que un evaluador te pedirá que enumeres.
La cabeza de la distribución es conocida y abrumadoramente de Google:
| Puesto | Host de terceros | Cuota de configuraciones de páginas de pago monitorizadas |
|---|---|---|
| 1 | www.googletagmanager.com (Google Tag Manager) | 39,7% |
| 2 | www.gstatic.com (contenido estático de Google) | 19,4% |
| 3 | www.google.com (reCAPTCHA, cuentas y otros servicios de Google) | 17,1% |
| 4 | connect.facebook.net (Meta Pixel) | 13,0% |
| 5 | pagead2.googlesyndication.com (Google Ads) | 11,4% |
| 6 | www.google-analytics.com (Google Analytics) | 10,6% |
| 7 | googleads.g.doubleclick.net (Google Ads / DoubleClick) | 9,5% |
| 8 | static.cloudflareinsights.com (Cloudflare) | 9,2% |
| 9 | www.blogger.com (Google) | 9,2% |
| 10 | apis.google.com (APIs de Google) | 7,9% |
Esos diez hosts suponen alrededor del 41% de la presencia en las páginas monitorizadas. Llegar al 80% exige unos 100 hosts, y detrás de ellos hay una cola de más de 9.000 hosts de terceros distintos. En un índice Herfindahl-Hirschman la superficie puntúa unos 0,023 en una escala de 0 a 1, lo que describe un mercado fragmentado.
Pasada la cabeza, los checkouts dejan de parecerse entre sí, y no existe una lista común de sospechosos habituales sobre la que puedan trabajar un evaluador o un equipo de riesgo de proveedores.
La mitad la cargó otro script
Los recuentos anteriores no dicen nada sobre quién puso el código en la página, y ahí es donde empieza el problema de cumplimiento.
Cuando cside clasifica los scripts distintos de las páginas de pago monitorizadas según cómo se cargaron, el 48% fue traído de forma demostrable por otro script. El 52% restante apareció sin ningún padre registrado, es decir, lo cargó el HTML de la propia página o faltaban los metadatos de su padre.
Medido en saltos desde la página hacia fuera, alrededor del 65% de las páginas alcanza una cadena de tres saltos: la página carga un script, ese script carga un segundo y el segundo carga un tercero. La medición está topada en tres saltos, así que las cadenas reales de esas páginas pueden ser más profundas. Solo en torno al 31% de las páginas se detiene en un único salto.
| Etapa | Punto de contacto | Detecta | No detecta | Resumen |
|---|---|---|---|---|
| HTML de la página | Comercio | Scripts que añadió el equipo; Proveedores con contrato; Visibles en el tag manager | Lo que esos scripts carguen después | Solo el 31% de las páginas se detiene en este salto |
| Primer salto | Proveedor | El proveedor que contrataste | Lo que ese proveedor carga después; Cambios enviados sin aviso | El 48% de los scripts llega a través de otro script |
| Segundo salto+ | Subproveedor | — | En ningún inventario; Sin contrato con el comercio; Sin aviso de cambios | El 65% de las páginas llega al menos hasta aquí |
Añadir un tag manager es una decisión del comercio. Todo lo que ese contenedor cargue después es decisión de otro, tomada sin aviso, en la página que maneja los datos de tarjeta.
Google Tag Manager es el inyector más común, y sobre todo inyecta Google
Google Tag Manager es, con diferencia, el tercero más frecuente en las páginas de pago: está presente en cerca del 40% de las configuraciones PCI monitorizadas y en torno al 38% de los dominios registrables. Es además el inyector más común.
Una concentración así se lee como riesgo de cadena de suministro hasta que miras qué está cargando GTM. De todo lo que se observó que GTM inyectaba en páginas de pago, alrededor del 93% era el propio stack de publicidad y analítica de Google. En torno al 7% apuntaba a un tercero realmente ajeno a Google.
La mayor parte de la exposición es, por tanto, una dependencia de Google hacia Google. Sigue siendo exposición, pero hacia una parte con la que el comercio ya tiene contrato. El 7% es la parte impredecible: código arbitrario de terceros que llega a una página de pago a través de un contenedor de confianza, elegido por quien tiene acceso al contenedor y no por quien responde del cumplimiento de PCI.
El etiquetado del lado del servidor amortiguaría esto, y casi nadie lo usa. Menos de cinco de cada cien mil peticiones a GTM en páginas de pago monitorizadas llevaban un prefijo de servidor.
Junio de 2026: el drenador de carteras de Polymarket
En junio de 2026, unos atacantes comprometieron a un proveedor externo e inyectaron un script drenador de carteras en el frontend de Polymarket, la plataforma de mercados de predicción. El script se llevó aproximadamente 3 millones de dólares de las carteras de un número reducido de usuarios. Ni los contratos inteligentes ni la cadena que hay debajo intervinieron: el robo se ejecutó en el navegador, a través de un script de terceros en el que la plataforma confiaba desde hacía meses.
No había ningún formulario de pago que raspar, así que el código inyectado no se comportó como un skimmer de tarjetas. Operó dentro de la interfaz, emitiendo solicitudes de aprobación de cartera a través de la propia UI de Polymarket. Los usuarios las aprobaron porque nada en la interfaz parecía fuera de lugar.
Los detalles cripto son accesorios. Lo que queda es un script de terceros de confianza, a varios saltos de distancia de cualquier cosa que la plataforma eligiera deliberadamente, que se vuelve malicioso en el navegador; y el mismo mecanismo funciona igual de bien contra los campos de tarjeta de un checkout. El desglose técnico completo de cside está en Dentro del ataque de cadena de suministro del lado del cliente a Polymarket de $3M.
La mayoría de las alertas son bibliotecas desactualizadas
Cuando la monitorización de scripts de cside salta en una página dentro del alcance de PCI, la mezcla está muy desequilibrada.
| Categoría de alerta | Cuota |
|---|---|
| Vulnerabilidades conocidas en bibliotecas JavaScript (dependencias con CVE asociado) | 88% |
| Scripts maliciosos conocidos / malware | 9% |
| Otras alertas de integridad de scripts o sin categorizar | 3% |
Aproximadamente nueve de cada diez alertas son bibliotecas desactualizadas con CVE publicados: un problema de parcheo e inventario, y donde se concentra la mayor parte del trabajo diario. El 9% que corresponde a scripts maliciosos conocidos tiene severidad crítica y llega por el mismo canal de monitorización que el ruido de las bibliotecas. Cualquier filtro lo bastante amplio como para acallar el otro 91% también los ocultará.
Qué hacer al respecto
- Inventaría lo que cargan tus etiquetas. Una lista de lo que añadió tu equipo no es un inventario 6.4.3 cuando el 48% de lo que se ejecuta lo cargó otra cosa. Pregunta a tus proveedores de primer nivel qué traen consigo aguas abajo, y trata como no medida cualquier página en la que no puedas responder a eso.
- Presupuesta para el percentil 99. Un inventario de doce scripts cabe en una hoja de cálculo; con 259 hacen falta herramientas y un responsable con nombre y apellidos. Averigua cuál de tus páginas de checkout es la atípica antes de que lo descubra un evaluador.
- Dimensiona la detección de cambios contra el ritmo real. Nueve de cada diez páginas ven un script nuevo en menos de dos semanas, con una mediana de 8. Un control de siete días que abra una revisión manual por cada cambio se quedará atrás en el primer ciclo, así que decide de antemano qué se clasifica de forma automática.
- Vigila el comportamiento en tiempo de ejecución. Un drenador o un skimmer a tres saltos de profundidad en una cadena no aparecerá en un escaneo estático de lo que pretendías instalar y, en el caso de Polymarket, no había nada del lado del servidor sobre lo que alertar.
Notas de metodología e higiene de datos
- Ventana y población. Todas las cifras de páginas de pago proceden de los 14 días que terminaron el 2026-07-22, tomadas de páginas designadas como dentro del alcance de PCI en la configuración de monitorización de cside. La población es la base de clientes monitorizada por cside en comercio electrónico, venta de entradas, organizaciones sin ánimo de lucro, hostelería y servicios financieros. No es una muestra aleatoria de la web, así que la distribución puede estar sesgada respecto a internet en su conjunto. Aquí no se caracteriza la dirección de ese sesgo.
- Definición de tercero. «Tercero» excluye cualquier recurso servido desde el propio dominio registrable de la página de pago, y excluye la infraestructura de la propia cside (
csidetm.com,csidefd.com,cside.com,cside.dev,client-side.dev). - Los hosts no son proveedores. Los recuentos por página de este informe son hosts de scripts de terceros distintos y scripts distintos, no empresas proveedoras normalizadas. Un mismo proveedor suele servir desde varios hosts, así que los recuentos de hosts salen más altos que los de proveedores. Cuando se cuentan entidades proveedoras por separado, la superficie está más concentrada arriba: las 10 principales entidades proveedoras cubren alrededor del 51% de las observaciones por inquilino y dominio, frente al 41% de los 10 hosts principales.
- El alcance se mide por configuración. La tabla de alcance por host cuenta configuraciones distintas de páginas de pago monitorizadas, un nivel de detalle próximo al dominio registrable pero no idéntico. Medido por dominio registrable, el alcance de Google Tag Manager ronda el 38% en lugar del 39,7%. El 41% de los diez primeros es otra unidad distinta: la cuota de presencia en las páginas monitorizadas.
- Clasificación del cargador. Un script distinto se cuenta como cargado en cadena cuando se observó con un padre no vacío. El grupo restante mezcla scripts cargados por el HTML de la página con scripts cuyos metadatos de padre faltaban; con los campos disponibles no es posible separar ambos casos, así que el 52% es una cota superior de los scripts realmente cargados por la página.
- La profundidad de cadena está topada. La profundidad se mide en saltos desde la página y se topa en tres. Las páginas del grupo «3 o más» pueden arrastrar cadenas más profundas que no se miden, así que las cifras de profundidad son un suelo. La profundidad se ancla en páginas que exponen al menos una arista de carga desde la raíz de la página; las páginas sin ella quedan excluidas.
- Contadores aproximados. Los recuentos de entidades distintas usan estimación aproximada de cardinalidad, con un error de en torno a medio punto porcentual. Las cuotas y los valores del índice lo heredan.
- Categorías de alerta. Las cuotas por categoría proceden del pipeline de alertas de scripts de cside en la misma ventana, agrupadas por clase de vulnerabilidad. Los recuentos absolutos de alertas y de sitios no se publican de forma deliberada.
- k-anonimato. Cualquier desglose con menos de 10 inquilinos en un grupo se suprime para evitar la divulgación involuntaria de un solo comercio.
- Contexto de los ataques. El caso de Polymarket se basa en informes públicos del incidente y en el análisis ya publicado por cside. No es un recuento interno de detecciones.
- Fuentes que corroboran. Sansec publica investigación de Magecart con familias identificadas, el DBIR de Verizon hace seguimiento de los patrones de filtración de tarjetas de pago, el PCI Security Standards Council publica los requisitos vigentes de PCI DSS 4.0.1, y OWASP y MITRE ATT&CK aportan la taxonomía a la que se corresponden las categorías de este informe.
Datos del informe actualizados a julio de 2026. cside es una plataforma de seguridad del lado del cliente que monitoriza el JavaScript en las propiedades web de sus clientes. Para más información, visita cside.com.
