En bref : comment fonctionnent les attaques Magecart
- Vraies victimes, vraies équipes : Au moins sept équipes d'attaquants injectant du JavaScript sur des pages de paiement. British Airways (380k enregistrements), Ticketmaster, Newegg, Warner Music.
- S'exécute après le WAF : L'attaque s'exécute après que votre WAF a approuvé la page, dans le même contexte JavaScript que votre formulaire de checkout.
- Les règles qui ferment : 6.4.3 et 11.6.1 ferment cette brèche. Requis depuis le 31 mars 2025 pour quiconque touche une page de paiement.
Peu de temps ? Découvrez le blocage Magecart et skimmer dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
L'attaque en trois mouvements
Toute campagne de skimming, quel que soit le groupe qui la mène, se ramène au même cycle. Enlevez le branding et vous obtenez trois mouvements.
| Mouvement | Ce qui se passe | Où cela vit |
|---|---|---|
| Injecter | L'attaquant parvient à faire charger son JavaScript sur votre page | Un fichier first-party compromis, un tag tiers ou un tag manager |
| Capturer | Le script lit les données de carte ou d'identifiants depuis le formulaire | Le DOM et les event listeners de formulaire dans le navigateur |
| Exfiltrer | Une copie des données est envoyée au serveur de l'attaquant | Une requête sortante du navigateur vers un domaine de l'attaquant |
Le reste de cet article parcourt chaque mouvement dans l'ordre, parce que l'ordre est ce qui rend l'attaque invisible.
Mouvement 1 : comment le code arrive sur la page
L'attaquant a besoin que son JavaScript s'exécute dans le navigateur du visiteur. Il dispose de trois routes courantes vers la page, aucune ne nécessite de toucher à la logique de votre serveur d'origine.
- Un fichier auto-hébergé. Il obtient un accès en écriture via un plugin vulnérable, un CMS obsolète ou un login admin volé, puis ajoute quelques lignes à un fichier JavaScript que vous livrez déjà. Le changement est petit et souvent dissimulé dans du code légitime, donc un diff paraît anodin.
- Un script tiers. Il compromet un vendor dont vous chargez le script directement avec
<script src>, tel qu'un widget d'analytics, de chat ou de test A/B. Désormais le skimmer est livré depuis le domaine du vendor à chaque client qui charge votre page, et il n'est jamais dans votre dépôt à trouver, ce qui explique pourquoi sécuriser les scripts tiers est une discipline à part entière. - Un tag manager. Il prend le contrôle d'un conteneur Google Tag Manager ou équivalent et ajoute un tag contenant le skimmer. Chaque site et page utilisant ce conteneur exécute désormais le code, y compris les pages de checkout où le tag n'a aucune raison de se charger.
Les routes tiers et tag manager passent à l'échelle, ce qui les rend dangereuses. Un vendor compromis sème des skimmers sur chaque site qui lui fait confiance, et un script que vous avez approuvé peut tirer un autre script que vous n'avez jamais revu, le problème de quatrième partie. C'est la forme supply-chain que visent les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 en demandant un inventaire et une autorisation de chaque script sur une page de paiement. La breach Ticketmaster de 2018 a suivi exactement ce chemin : le skimmer a atteint le checkout via le script de chatbot d'un fournisseur compromis, pas via le code propre de Ticketmaster (résumé Wikipédia de l'incident de 2018).
Mouvement 2 : comment le skimmer lit votre formulaire
Une fois le script exécuté, lire le formulaire est du développement web ordinaire retourné contre vous. Lire et modifier le DOM est la façon dont fonctionne tout framework moderne, donc les actions du skimmer ressemblent à un comportement de page normal. Un skimmer fait généralement une ou plusieurs des choses suivantes :
- Lit les valeurs d'input directement. Il sélectionne les champs de numéro de carte, d'expiration, de CVV et de nom par leurs attributs
id,nameouautocompleteet lit.valuedirectement depuis le DOM. - Attache des event listeners. Il accroche
input,keyup,changeoublursur les champs de paiement, afin de capturer chaque frappe même si l'utilisateur ne soumet jamais le formulaire. - Détourne le chemin de submit. Il enveloppe le handler de submit du formulaire ou accroche le bouton « payer », assemblant le payload complet au moment où l'utilisateur valide.
- Patche les primitives réseau. Les skimmers avancés surchargent
fetch,XMLHttpRequest.prototype.sendounavigator.sendBeaconpour lire la vraie requête de paiement pendant que votre propre code l'envoie. - Superpose un faux champ. Certains injectent une iframe de paiement contrefaite par-dessus la vraie, afin que l'acheteur tape les détails de carte directement dans l'input de l'attaquant. La propre analyse de cside d'une campagne Magecart a trouvé une fausse frame de paiement insérée au checkout via une seule ligne JavaScript obfusquée, le type de substitution qu'un scan côté serveur ne voit jamais.
Le serving conditionnel est ce qui le garde silencieux
Le skimmer ne se déclenche pas pour tout le monde. Il se filtre afin que les personnes les plus susceptibles de le repérer, à savoir les équipes de sécurité, les scanners et les bots, ne voient jamais le comportement malveillant :
- Filtrage par chemin. Beaucoup de skimmers ne s'arment que sur des URLs qui correspondent à un motif de checkout ou de login, donc le code dort partout ailleurs.
- Détection d'automatisation. Lire
navigator.webdriverrenvoietruedans les navigateurs headless et automatisés, donc le skimmer peut servir du code propre à un scanner et le vrai payload à un acheteur. Les variantes plus avancées recherchent les globales Selenium ou les fuitesRuntimedu Chrome DevTools Protocol (CDP) pour repérer les navigateurs instrumentés. - Déclenchement unique par session. Exfiltrer une seule fois évite le bruit réseau dupliqué qui pourrait ressortir dans un log.
Cette course aux armes s'accélère aussi du côté attaquant : le rapport de recherche Future of Web Security 2026 de cside a suivi playwright-stealth croître d'environ dix fois durant 2025, une automatisation conçue pour battre navigator.webdriver et des vérifications similaires. La même évasion qui cache l'outillage d'un attaquant aux défenseurs est ce qui cache un skimmer aux vôtres. Le code est généralement obfusqué par-dessus tout ça, ce qui ensevelit l'intention lors d'une revue manuelle.
Mouvement 3 : comment les données partent
La capture est inutile pour l'attaquant tant que les données ne lui parviennent pas. L'exfiltration est une requête sortante unique depuis le navigateur, et l'attaquant dispose de plusieurs moyens discrets de l'envoyer.
| Méthode | Aspect sur le réseau |
|---|---|
navigator.sendBeacon() | Un petit POST qui se déclenche de façon fiable au déchargement, conçu pour l'analytics, donc il se fond dans le trafic |
fetch() / XMLHttpRequest | Une requête async standard, souvent vers un domaine look-alike qui imite un CDN ou un host d'analytics |
| Requête image | Le payload est ajouté au src d'un <img> comme query string ; le navigateur « charge » une image qui est en réalité un dépôt de données |
| WebSocket | Un canal persistant pour transmettre les frappes capturées en quasi temps réel |
Trois propriétés rendent cette fuite quasi impossible à repérer de l'extérieur. La requête est en HTTPS, donc chiffrée comme tout le reste de votre trafic. La destination est généralement un domaine typosquatté ou fraîchement enregistré qui se lit comme un vrai vendor. Le skimmer de British Airways exfiltrait vers baways.com, donc cela ne saute pas aux yeux dans un log. Et le payload est minuscule et souvent encodé en base64, donc il ressemble à un ping de télémétrie de routine. Élément critique : cette requête va du navigateur directement à l'attaquant ; elle ne passe jamais par votre origine, votre WAF ni votre passerelle de paiement. C'est toute la raison pour laquelle le vol est invisible côté serveur.
Pourquoi votre serveur, votre WAF et votre processeur ne voient rien
Mettez les trois mouvements ensemble et l'angle mort est évident. Le code s'est chargé dans le navigateur, a lu le champ dans le navigateur et a envoyé la copie depuis le navigateur vers un troisième domaine. Votre backend n'a jamais vu que la transaction légitime et autorisée.
- Un pare-feu d'application web (WAF) inspecte les requêtes qui arrivent à votre origine. La requête d'exfiltration n'y arrive jamais, donc le WAF n'a rien à inspecter.
- Un SIEM agrège les logs serveur et infrastructure, et le skimmer ne génère aucun événement serveur. La surveillance de la fraude signale les anomalies d'achat, mais l'achat réel s'est terminé exactement comme prévu.
- Un processeur de paiement comme Stripe ou Adyen sécurise la transaction qu'il reçoit. Si vos champs de carte se trouvent sur votre propre page, un skimmer les lit avant même que le processeur ne soit impliqué, et votre page reste redevable de sa propre preuve PCI DSS 4.0.1 6.4.3 et 11.6.1, quel que soit le processeur.
L'attaque vit dans un runtime que votre stack côté serveur ne peut pas atteindre. Un problème côté client nécessite une défense côté client.
Comment la surveillance en couche navigateur attrape chaque mouvement
La détection doit se poser là où le skimmer tourne. cside surveille les scripts et le comportement dans le navigateur, donc chaque mouvement laisse un signal sur lequel elle peut agir.
- Injecter apparaît comme un script nouveau ou modifié. cside tient un inventaire des scripts et signale les ajouts, changements et tags tiers manipulés dès qu'ils surviennent, pas des semaines plus tard dans un rapport de fraude.
- Capturer apparaît comme du comportement. Des listeners inattendus sur les champs de paiement, du code lisant des inputs qu'il ne devrait pas, et des overrides de
fetchousendBeaconsont des anomalies runtime par rapport à une baseline connue-bonne. - Exfiltrer apparaît comme une destination. cside remonte les requêtes sortantes vers des domaines absents de votre allowlist, le mouvement caractéristique d'un skimmer qui tente de sortir.
Parce que cside tourne dans de vrais navigateurs plutôt que dans un scanner de salle blanche, le serving conditionnel ne cache pas le skimmer comme il le cache à un crawler headless. Cette même visibilité produit la preuve qu'attend PCI DSS 4.0.1 : un inventaire autorisé des scripts de page de paiement pour 6.4.3, et des alertes sur les changements non autorisés du contenu et des en-têtes de script pour 11.6.1, tous deux obligatoires depuis le 31/03/2025.
Lectures complémentaires sur cside
- Qu'est-ce que le skimming de carte en ligne ?
- Qu'est-ce que Magecart : guide complet et stratégie de prévention
- Formjacking vs Magecart vs digital skimming
- Que sont les skimmers numériques ?
- Les plus grandes attaques Magecart de l'histoire (jusqu'ici)
- cside client-side security
Incidents Magecart nommés (2018 à 2024)
L'écosystème Magecart est une fédération lâche d'au moins sept groupes distincts (numérotés Group 1 à Group 12 par RiskIQ) utilisant des TTP partagés. Les divulgations publiques ci-dessous sont les cas de référence que les clients et les QSA citent lors de la définition des contrôles PCI DSS 4.0.1 §6.4.3 et §11.6.1.
- British Airways (2018). Environ 380 000 enregistrements de cartes de paiement exfiltrés sur 15 jours à partir d'un script compromis servi sur les pages de checkout et de l'application mobile. Amende de l'ICO britannique réduite de 183 M£ à 20 M£.
- Ticketmaster UK (2018). Détails de carte d'environ 40 000 clients exposés après que le script de support client Inbenta, servi depuis un CDN tiers, a été modifié pour skimmer la page de paiement. Amende ICO de 1,25 M£.
- Newegg (2018). 15 lignes de JavaScript injecté ont capturé toutes les données de carte soumises à
checkout/payment.aspxpendant 35 jours. Attribution à Magecart Group 4 par RiskIQ. - Warner Music Group (2020). Plusieurs sites e-commerce exploités par WMG aux États-Unis et au Royaume-Uni compromis pendant trois mois, ciblant les données de checkout sur la plateforme Volusion.
- Segway (2022). Les attaquants ont utilisé une extension Magento malveillante pour skimmer les formulaires de paiement, divulgué par Malwarebytes.
- Kaiser Permanente (2024). 13,4 millions de membres notifiés après que des scripts d'analytics et de tracking tiers sur des pages destinées aux membres ont exposé des informations sensibles, un cas adjacent à la même classe de TTP Magecart.
- Chaîne d'approvisionnement Polyfill.io (2024). Après un changement de propriété,
cdn.polyfill.ioa commencé à servir du code malveillant à plus de 100 000 sites intégrant la bibliothèque, divulgué par Sansec. Fastly, Cloudflare et Google sont intervenus au niveau réseau. - Adobe Commerce / Magento Cosmicsting (CVE-2024-34102). Faille de désérialisation XML côté serveur utilisée pour implanter des skimmers côté client sur des centaines de marchands Magento en 2024 et jusqu'en 2025.
Chaque cas ci-dessus a contourné les défenses côté serveur du marchand et manipulé du code exécuté par le navigateur. C'est exactement l'écart que PCI DSS 6.4.3 (autorisation et intégrité des scripts) et 11.6.1 (détection de changement sur la page de paiement) ont été écrits pour combler.
