Magecart est du web skimming qui s'exécute dans le navigateur. Du JavaScript malveillant atterrit sur une page de checkout ou de login, lit ce que le visiteur tape dans le formulaire et envoie une copie à un serveur contrôlé par l'attaquant. Le paiement légitime passe toujours, donc du point de vue de vos serveurs cela ressemble à une journée normale de transactions propres. Tout a l'air normal pendant que les données carte partent, et cet écart est tout le problème.
Cet article explique la mécanique pour quelqu'un qui rencontre la menace pour la première fois. Ce n'est pas une politique de prévention ni la taxonomie formjacking-vs-Magecart. Il parcourt la séquence réelle : comment le code entre, comment il capture les données et comment il sort. Comprenez ces trois mouvements et vous comprenez pourquoi un WAF, un SIEM et un processeur de paiement peuvent tous être au vert pendant qu'un skimmer tourne. cside surveille directement cette couche navigateur, observe chaque script pendant qu'il s'exécute et signale le moment où l'un commence à lire des champs ou à appeler un domaine qu'il n'avait jamais touché auparavant, ce qui est la base pour détecter Magecart en temps réel plutôt qu'après la breach.
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 swap 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 croissant d'environ dix fois durant 2025, de l'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 |
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 drop 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 votre autre 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 elle 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. 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 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 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 sont sur votre propre page, un skimmer les lit avant 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 client-side nécessite une défense client-side.
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 quand 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 2025-03-31.
