Rapport sur les attaques côté client T3 2026 : l'état de la sécurité des pages de paiement

Rédigé par Mike Kutlu, cside. Les chiffres relatifs aux pages de paiement proviennent de la télémétrie navigateur en production de cside, sur les 14 jours arrêtés au 2026-07-22, pour des pages relevant du périmètre PCI. Le contexte des attaques s'appuie sur les signalements publics d'incidents et sur les analyses publiées par cside. La méthodologie et ses limites sont exposées en fin d'article. Dernière relecture : juillet 2026.

L'essentiel

• La page de paiement médiane relevant du périmètre PCI charge 3 noms d'hôte de scripts tiers distincts. Le 90e centile en charge 9, le 99e centile 22.
• Environ 48 % des scripts distincts présents sur ces pages ont été chargés par un autre script, et non par le HTML de la page, et environ 65 % des pages portent une chaîne de dépendances d'au moins trois maillons.
• La surface est fragmentée. Les 10 premiers noms d'hôte couvrent environ 41 % de la présence sur les pages surveillées, mais il en faut une centaine pour atteindre 80 %, et la traîne dépasse 9 000 noms d'hôte.
• 91,6 % des pages ont servi, pendant la fenêtre d'observation, au moins un script qu'elles n'avaient jamais servi auparavant, avec une médiane de 8 nouveaux scripts par page.
• En juin 2026, un fournisseur tiers compromis a placé un script videur de portefeuilles dans le frontend de Polymarket et prélevé environ 3 millions de dollars sur les portefeuilles d'utilisateurs, sans compromettre de serveur ni toucher au moindre contrat intelligent.

Peu de temps ? Découvrez le blocage in-browser des Magecart et skimmers de cside. Elle couvre tout ce qui suit en un seul déploiement.

Synthèse

Les marchands savent en général nommer les tiers qu'ils ont ajoutés à un tunnel de paiement. Ce qu'ils ne savent pas nommer, c'est le code que ces tiers amènent avec eux, et c'est précisément ce que mesure ce rapport.

Sur les tunnels de paiement relevant du périmètre PCI que cside surveille, la page médiane charge 3 noms d'hôte de scripts tiers distincts, ce qui paraît gérable. Mais 48 % des scripts distincts observés sur ces pages sont arrivés par l'intermédiaire d'un autre script plutôt que par le HTML de la page, et environ 65 % des pages portent une chaîne de chargement qui s'éloigne d'au moins trois maillons de la page. Le marchand a choisi le premier maillon ; un fournisseur, ou le fournisseur d'un fournisseur, a choisi les suivants.

L'exigence PCI DSS 6.4.3 demande un inventaire de chaque script présent sur la page de paiement, assorti d'une justification métier. À la médiane, cela représente environ 12 scripts, qu'une équipe conformité traite en une après-midi. Au 99e centile, il y en a environ 259, chargés pour la plupart en cascade, et personne chez le marchand n'est en mesure d'en justifier la majeure partie.

L'inventaire ne reste pas figé non plus. En deux semaines, 91,6 % des pages de paiement surveillées ont servi au moins un script qu'elles n'avaient jamais servi auparavant, avec une médiane de 8 nouveaux scripts par page. L'exigence 11.6.1 demande une détection des changements au moins tous les sept jours ; c'est ce volume qu'un tel contrôle doit absorber.

En juin 2026, un fournisseur tiers compromis a injecté un videur de portefeuilles dans le frontend de Polymarket et siphonné environ 3 millions de dollars sur les portefeuilles d'utilisateurs. Rien n'a été compromis côté serveur et les contrats n'ont pas été touchés : toute la compromission s'est jouée dans le navigateur.

Chaque décompte porte sur un tiers véritable. Les scripts propriétaires du marchand et l'infrastructure de cside sont exclus.

Ce que charge réellement une page de paiement

L'inventaire exigé par 6.4.3 commence par un choix d'unité de mesure, et les deux unités disponibles donnent des réponses très différentes.

Mesurée au niveau des noms d'hôte, la page médiane reste modeste : 3 noms d'hôte de scripts tiers distincts, 9 au 90e centile, 22 au 99e. Mesurées en scripts individuels, les mêmes pages affichent une médiane de 12, un 90e centile de 46 et un 99e centile d'environ 259. Le décompte des noms d'hôte indique à combien de parties distinctes la page s'adresse ; le décompte des scripts est ce qu'un auditeur vous demandera d'énumérer.

La tête de distribution est familière et très majoritairement Google :

Ces dix noms d'hôte représentent environ 41 % de la présence sur les pages surveillées. Atteindre 80 % en demande une centaine, et derrière eux s'étend une traîne de plus de 9 000 noms d'hôte tiers distincts. Sur un indice de Herfindahl-Hirschman, la surface obtient environ 0,023 sur une échelle de 0 à 1, ce qui correspond à un marché fragmenté.

Passé la tête de distribution, les tunnels de paiement cessent de se ressembler, et il n'existe aucune liste partagée de suspects habituels sur laquelle un auditeur ou une équipe de risque fournisseur puisse s'appuyer.

La moitié a été chargée par un autre script

Les décomptes ci-dessus ne disent rien de qui a placé le code sur la page, et c'est là que commence le problème de conformité.

Quand cside classe les scripts distincts des pages de paiement surveillées selon leur mode de chargement, 48 % ont manifestement été appelés par un autre script. Les 52 % restants sont apparus sans parent enregistré, ce qui signifie qu'ils ont été chargés par le HTML de la page ou que les métadonnées de leur parent manquaient.

Mesurées en maillons depuis la page, environ 65 % des pages atteignent une chaîne de trois maillons : la page charge un script, ce script en charge un deuxième, et le deuxième en charge un troisième. Cette mesure est plafonnée à trois maillons, si bien que les chaînes réelles de ces pages peuvent aller plus loin. Seules 31 % environ des pages s'arrêtent à un seul maillon.

Ajouter un gestionnaire de balises est une décision du marchand. Tout ce que ce conteneur charge ensuite relève de la décision de quelqu'un d'autre, prise sans préavis, sur la page qui traite les données de carte.

Google Tag Manager est l'injecteur le plus courant, et il injecte surtout du Google

Google Tag Manager est le tiers le plus répandu sur les pages de paiement : il est présent sur environ 40 % des configurations PCI surveillées et sur près de 38 % des domaines enregistrables. C'est aussi l'injecteur le plus courant.

Une telle concentration ressemble à un risque de chaîne d'approvisionnement, jusqu'à ce qu'on regarde ce que GTM charge. Sur tout ce que GTM a été observé en train d'injecter sur des pages de paiement, environ 93 % relevait de la pile publicitaire et analytique de Google elle-même. Environ 7 % pointait vers un tiers réellement extérieur à Google.

L'essentiel de l'exposition est donc une dépendance de Google envers Google, ce qui reste une exposition, mais envers une partie avec laquelle le marchand a déjà un contrat. Les 7 % constituent la part imprévisible : du code tiers arbitraire qui atteint une page de paiement via un conteneur de confiance, choisi par qui détient l'accès au conteneur plutôt que par qui porte la conformité PCI.

Le marquage côté serveur atténuerait le problème, et presque personne ne l'utilise. Moins de cinq requêtes GTM sur cent mille observées sur les pages de paiement surveillées portaient un préfixe côté serveur.

Juin 2026 : le videur de portefeuilles de Polymarket

En juin 2026, des attaquants ont compromis un fournisseur tiers et injecté un script videur de portefeuilles dans le frontend de la plateforme de marchés prédictifs Polymarket. Le script a prélevé environ 3 millions de dollars sur les portefeuilles d'un petit nombre d'utilisateurs. Les contrats intelligents et la blockchain sous-jacente n'ont joué aucun rôle : le vol s'est exécuté dans le navigateur, via un script tiers auquel la plateforme faisait confiance depuis des mois.

Il n'y avait aucun formulaire de paiement à écrémer, et le code injecté ne s'est donc pas comporté comme un skimmer de carte. Il opérait à l'intérieur de l'interface, en émettant des demandes d'approbation de portefeuille à travers l'interface même de Polymarket. Les utilisateurs les ont validées parce que rien ne clochait à l'écran.

Les spécificités crypto sont accessoires. Ce qu'il reste, c'est un script tiers de confiance, situé à plusieurs maillons de tout ce que la plateforme avait délibérément choisi, qui devient malveillant dans le navigateur, et le même mécanisme fonctionne tout aussi bien contre les champs de carte d'un tunnel de paiement. L'analyse technique complète de cside se trouve dans Au cœur de l'attaque de chaîne d'approvisionnement côté client de $3M contre Polymarket.

La plupart des alertes concernent des bibliothèques obsolètes

Quand la surveillance de scripts de cside se déclenche sur une page relevant du périmètre PCI, la répartition est déséquilibrée.

Près de neuf alertes sur dix concernent des bibliothèques obsolètes affectées par des CVE publiées : un problème de correctifs et d'inventaire, et c'est là que se concentre l'essentiel du travail quotidien. Les 9 % de scripts malveillants connus sont de gravité critique, et ils empruntent le même canal de surveillance que le bruit des bibliothèques. Tout filtre assez large pour faire taire les 91 % restants les masquera aussi.

Que faire

1. Inventoriez ce que vos balises chargent. La liste de ce que votre équipe a ajouté n'est pas un inventaire au sens de 6.4.3 quand 48 % de ce qui s'exécute a été chargé par autre chose. Demandez à vos fournisseurs de premier niveau ce qu'ils entraînent en aval, et considérez comme non mesurée toute page pour laquelle vous ne pouvez pas répondre.
2. Dimensionnez pour le 99e centile. Un inventaire de douze scripts tient dans un tableur ; à 259, il faut de l'outillage et un responsable désigné. Repérez laquelle de vos pages de paiement est l'exception avant qu'un auditeur ne le fasse.
3. Calibrez la détection des changements sur le rythme réel. Neuf pages sur dix voient un nouveau script en moins de deux semaines, avec une médiane de 8. Un contrôle hebdomadaire qui déclenche une revue manuelle à chaque changement décrochera dès le premier cycle : décidez à l'avance ce qui sera trié automatiquement.
4. Surveillez le comportement à l'exécution. Un videur ou un skimmer situé à trois maillons dans une chaîne n'apparaîtra pas dans une analyse statique de ce que vous pensiez avoir installé, et dans le cas Polymarket il n'y avait de toute façon rien côté serveur sur quoi alerter.

Méthodologie et notes d'hygiène des données

• Fenêtre et population. Tous les chiffres relatifs aux pages de paiement portent sur les 14 jours arrêtés au 2026-07-22, à partir de pages désignées comme relevant du périmètre PCI dans la configuration de surveillance de cside. La population correspond à la base de clients surveillés par cside : e-commerce, billetterie, associations, hôtellerie-restauration et services financiers. Ce n'est pas un échantillon aléatoire du web, et la distribution peut donc s'écarter de celle d'internet dans son ensemble. Le sens de cet écart n'est pas caractérisé ici.
• Définition d'un tiers. « Tiers » exclut toute ressource servie depuis le domaine enregistrable de la page de paiement elle-même, et exclut l'infrastructure de cside (csidetm.com, csidefd.com, cside.com, cside.dev, client-side.dev).
• Les noms d'hôte ne sont pas des fournisseurs. Les décomptes par page de ce rapport portent sur des noms d'hôte de scripts tiers distincts et sur des scripts distincts, pas sur des entreprises fournisseurs normalisées. Un même fournisseur sert couramment depuis plusieurs noms d'hôte, si bien que les décomptes de noms d'hôte dépassent les décomptes de fournisseurs. Quand les entités fournisseurs sont comptées séparément, la surface est plus concentrée en tête : les 10 premières entités couvrent environ 51 % des observations par client et par domaine, contre 41 % pour les 10 premiers noms d'hôte.
• La portée est mesurée par configuration. Le tableau de portée par nom d'hôte compte des configurations distinctes de pages de paiement surveillées, une granularité proche du domaine enregistrable sans lui être identique. Mesurée par domaine enregistrable, la portée de Google Tag Manager avoisine 38 % plutôt que 39,7 %. Les 41 % du top 10 relèvent encore d'une autre unité : la part de présence sur les pages surveillées.
• Classification du chargeur. Un script distinct est compté comme chargé en cascade lorsqu'il a été observé avec un parent non vide. Le reste regroupe les scripts chargés par le HTML de la page et ceux dont les métadonnées de parent manquaient ; ces deux cas ne peuvent pas être séparés avec les champs disponibles, donc 52 % constitue une borne supérieure des scripts réellement chargés par la page.
• La profondeur de chaîne est plafonnée. La profondeur se mesure en maillons depuis la page et est plafonnée à trois. Les pages du groupe « 3 et plus » peuvent porter des chaînes plus profondes qui ne sont pas mesurées : les chiffres de profondeur sont donc un plancher. La profondeur est établie sur les pages exposant au moins un lien de chargement depuis la racine de la page ; celles qui n'en exposent aucun sont exclues.
• Compteurs approximatifs. Les décomptes d'entités distinctes reposent sur une estimation approximative de cardinalité, avec une erreur d'environ un demi pour cent. Les parts et les valeurs d'indice en héritent.
• Catégories d'alertes. Les parts par catégorie proviennent du pipeline d'alertes de scripts de cside sur la même fenêtre, regroupées par classe de vulnérabilité. Les décomptes absolus d'alertes et de sites ne sont volontairement pas publiés.
• k-anonymat. Toute ventilation comptant moins de 10 clients dans un groupe est supprimée afin d'éviter la divulgation involontaire d'un marchand isolé.
• Contexte d'attaque. Le cas Polymarket s'appuie sur les signalements publics d'incidents et sur l'analyse publiée par cside. Il ne s'agit pas d'un décompte interne de détections.
• Sources corroborantes. Sansec publie des recherches sur les familles Magecart identifiées, le DBIR de Verizon suit les schémas de compromission de données de cartes de paiement, le PCI Security Standards Council publie les exigences actuelles de PCI DSS 4.0.1, et OWASP ainsi que MITRE ATT&CK fournissent la taxonomie à laquelle correspondent les catégories de ce rapport.

Données du rapport à jour en juillet 2026. cside est une plateforme de sécurité côté client qui surveille le JavaScript sur les propriétés web de ses clients. Pour en savoir plus, voir cside.com.