TL;DR : Les attaques Magecart
- Qu'est-ce qu'une attaque Magecart : Une attaque Magecart est une attaque de web skimming côté navigateur dans laquelle du JavaScript malveillant est injecté sur un site web dans le seul but de voler des données de carte bancaire ou des saisies de formulaires sensibles directement depuis le navigateur de l'utilisateur, lors du paiement ou de la connexion.
- Pourquoi les attaques Magecart sont difficiles à détecter : Magecart opère entièrement dans le navigateur ; les défenses traditionnelles comme les WAF, les SIEM et la surveillance des transactions ne voient rien d'anormal pendant que les paiements légitimes continuent d'aboutir.
- Comment prévenir les attaques Magecart : Une prévention efficace passe par la réduction des scripts sur les pages de paiement, la gouvernance et la surveillance des JavaScript tiers, l'application de contrôles navigateur comme CSP et SRI, et le déploiement d'un outil de surveillance côté client en continu comme cside.
« J'ai récemment été informé d'une violation de données sur votre boutique et ma carte bancaire a été utilisée frauduleusement. »
C'est le cauchemar du support client. Et ce n'est pas tout : vos équipes fraude et finance reçoivent également des alertes des émetteurs de cartes et des questions de la part des prestataires de paiement.
Magecart ne consiste pas à imiter des pages de connexion ou de paiement. Il s'agit de détourner vos vraies pages de connexion et de paiement, celles en lesquelles vos clients ont confiance.
C'est ça, Magecart : ce qui se passe quand votre connexion et votre tunnel de paiement deviennent le maillon faible de vos contrôles de sécurité. Même si vos serveurs, votre WAF et vos contrôles PCI sont solides, quelques lignes de JavaScript malveillant dans le navigateur peuvent collecter des données de carte et des PII pendant des semaines avant que quiconque ne s'en aperçoive.
Ce guide explique ce qu'est Magecart, comment il fonctionne, pourquoi il est difficile à détecter, et présente les outils de prévention contre Magecart.
Qu'est-ce qu'une attaque Magecart ?
Une attaque Magecart est une attaque de web skimming côté navigateur. Du JavaScript malveillant est injecté sur un site e-commerce dans un seul but : voler des données de carte bancaire.
C'est quelque chose que vous ne souhaitez ni à vous-même ni à vos clients. C'est un cauchemar pour les boutiques en ligne car cela détourne la confiance de vos clients. Les dommages causés aux entreprises en ligne sont considérables : pertes financières, rétrofacturations, amendes réglementaires et atteinte grave à la réputation.
Votre WAF et votre stack de sécurité côté serveur ne verront rien de tout cela. L'attaque se déroule entièrement dans le navigateur de l'utilisateur, dans un environnement de code que votre surveillance backend ne touche jamais. Même les contrôles liés à la PCI DSS comme le chiffrement ou la tokenisation ne servent à rien si l'attaquant vole les données de carte avant que ces défenses n'entrent en jeu. Les transactions de votre côté continuent de passer comme si de rien n'était. De votre point de vue, tout semble normal. Mais pendant ce temps, des données sont discrètement exfiltrées depuis le navigateur de votre client vers les serveurs de l'attaquant.
Magecart est une forme de web skimming
Magecart est une forme de web skimming (ou e-skimming). Le web skimming est la version en ligne du skimming de carte bancaire sur les distributeurs automatiques : les frappes ou saisies sont copiées par des dispositifs cachés et utilisées ensuite pour effectuer des achats frauduleux. Lorsque des attaquants ajoutent leur JavaScript malveillant à une boutique en ligne, cela leur ouvre de nombreuses possibilités. Ils peuvent voir ce qu'un utilisateur saisit dans les formulaires de paiement ou de connexion et exfiltrer discrètement ces données vers leurs propres systèmes.
Comment le terme « Magecart » a évolué
Vers 2015-2016, des chercheurs en sécurité ont commencé à signaler que des boutiques en ligne basées sur Magento étaient ciblées par des attaques de skimming de carte en ligne. Typiquement, du JavaScript était injecté dans les pages de paiement pour voler et exfiltrer des données de paiement et des PII. D'où le terme « Magecart » : « Mage » de Magento et « cart », abréviation de panier d'achat.
Au fil du temps, les attaques Magecart se sont étendues à d'autres plateformes et à des configurations e-commerce personnalisées. Toute plateforme utilisant du JavaScript côté client et des scripts tiers était vulnérable, pas seulement Magento.
Du skimming de carte sur Magento aux attaques de style Magecart partout
Magecart a évolué pour devenir un style d'attaque : une étiquette pour le skimming numérique, le formjacking, l'e-skimming, le skimming de carte en ligne, et il est devenu une menace majeure pour les plateformes de vente en ligne.
Magecart est moins le surnom d'un groupe spécifique qu'une étiquette générique désignant un écosystème de groupes et de techniques de skimming numérique. De manière générale, ils utilisent le même vecteur d'attaque mais s'appuient sur des infrastructures et des outils différents.
Comment fonctionnent les attaques Magecart
L'idée semble simple : copier les données d'un formulaire et les exfiltrer vers un point de terminaison compromis. Mais en réalité, ces attaques sont plus subtiles et sophistiquées. À chaque instant, la boutique en ligne doit se comporter normalement : aucune erreur, aucun délai d'attente.
Pour que le skimming numérique réussisse, ni vos systèmes de surveillance ni vos clients ne doivent remarquer quoi que ce soit d'inhabituel.
Voici comment se déroule typiquement une attaque Magecart dans le navigateur.
1. Injection de JavaScript malveillant sur le site
Tout d'abord, l'attaquant a besoin d'un moyen d'exécuter son propre JavaScript dans le navigateur de l'utilisateur, car c'est là que l'attaque se déroule. Il recherche des vulnérabilités telles que des plugins ou composants CMS obsolètes ou mal configurés, ou des scripts tiers négligés comme un plugin, des fichiers CDN, un gestionnaire de balises, etc.
Ce point faible devient le vecteur d'attaque : l'attaquant ajoute quelques lignes de son JavaScript malveillant à un fichier de production existant ou à un script tiers. La modification est minime, souvent noyée dans du code légitime, de sorte que rien ne ressort lors d'une revue de sécurité.
2. Lecture des données de paiement et de formulaire
Une fois cela fait, le JavaScript malveillant accède au DOM et lit les données saisies par l'utilisateur dans le formulaire. L'accès et la modification du DOM par JavaScript sont un comportement normal dans le développement web moderne. C'est ainsi que JavaScript rend les pages dynamiques sans recharger l'intégralité du document HTML. De nombreux frameworks comme React ou Svelte reposent sur la capacité de JavaScript à manipuler le DOM.
Le skimmer numérique se concentre alors sur des champs spécifiques du formulaire de paiement ou de connexion : numéro de carte, date d'expiration, CVV, nom, adresse, etc. Il copie ces valeurs sans modifier le formulaire ni le parcours utilisateur de quelque manière visible que ce soit.
3. Exfiltration des données vers le serveur de l'attaquant
Une fois les données capturées, l'étape suivante consiste à les transférer discrètement vers un serveur contrôlé par l'attaquant. La plupart du temps, le déclencheur de l'exfiltration est le clic de l'utilisateur sur le bouton « Payer »/« Valider ». À ce moment, le script assemble la charge utile (brute ou encodée) avec les détails de la carte, les PII, et souvent des informations contextuelles comme des horodatages ou des URL.
Les techniques d'exfiltration courantes incluent fetch, XMLHttpRequest pour le code ancien, les requêtes d'image cachées et navigator.sendBeacon(). TLS/HTTPS n'empêche pas l'exfiltration car elle ressemble à une requête https légitime, avec une charge utile très réduite. Les attaquants utilisent souvent des domaines très similaires aux noms d'hôtes légitimes des boutiques en ligne, des CDN ou des outils d'analyse afin de ne pas éveiller les soupçons. Si la requête d'exfiltration échoue, le code intercepte simplement l'erreur et ne s'exécute pas. Mais la transaction légitime, elle, aboutit.
4. Maintien du fonctionnement de la boutique et du traitement des commandes
Pour que l'attaque Magecart soit efficace, les transactions doivent continuer à affluer. Le skimmer exfiltre une copie des données, mais le formulaire de paiement est également soumis à votre backend et à votre passerelle de paiement. Les commandes sont créées, les paiements sont autorisés et vos systèmes de traitement des commandes se mettent en marche.
Comment les attaquants accèdent aux scripts web pour mener des attaques Magecart
Les attaquants scrutent les points faibles de votre stack web : les endroits où des scripts peuvent être modifiés et où du code de skimming peut s'infiltrer. Pour défendre votre site et construire un modèle de menace efficace, vous devez vous concentrer sur certains points d'entrée courants des attaques Magecart.
1. Magecart via les plugins, le CMS ou le code de la plateforme e-commerce
Votre propre CMS ou plateforme e-commerce constitue une surface d'attaque directe. Des plateformes comme Magento, WooCommerce, les applications Shopify et le code de paiement personnalisé nécessitent un examen régulier. Les points faibles typiques sont les plugins et extensions obsolètes, ou les modifications non sécurisées apportées aux templates ou aux fichiers JavaScript. Les comptes administrateurs nécessitent une protection renforcée : si un attaquant parvient à se connecter en tant qu'administrateur, la modification des scripts devient aisée.
Si votre boutique en ligne utilise un plugin de paiement ou de suivi obsolète dans Magento ou WooCommerce, le skimming numérique n'est qu'à une étape. Si les attaquants parviennent à modifier les fichiers du plugin ou à abuser d'un compte administrateur, il leur suffit de modifier un seul fichier JavaScript sur la page de paiement pour y ajouter leur skimmer.
2. Magecart via la chaîne d'approvisionnement de code tiers
Cela inclut tout point d'entrée via <script src> ou un gestionnaire de balises : bibliothèques CDN, outils de test A/B ou d'analyse pour votre équipe marketing, widget de chat/support pour le service client, etc. Ces scripts sont gérés et hébergés par des fournisseurs externes ou injectés via des gestionnaires de balises qui peuvent exécuter du code sur la plupart des pages. Il suffit d'un seul script tiers compromis ou d'un compte de gestionnaire de balises détourné pour propager du code de skimmer sur tous les sites et toutes les pages où ce code est utilisé.
Parfois, un compte Google Tag Manager (GTM) ou un widget de chat externe contient du code qui se charge sur l'ensemble du site (y compris les pages de paiement) même s'il n'y remplit aucune fonction. Si GTM est compromis et qu'une balise supplémentaire contenant du JavaScript de skimmer est ajoutée, chaque formulaire de paiement sur chaque site utilisant ce conteneur exécute désormais du code Magecart.
Pourquoi les attaques Magecart sont difficiles à détecter
Maintenant que nous avons vu comment une attaque Magecart fonctionne dans le navigateur, il est légitime de se demander : pourquoi les défenses traditionnelles ne la détectent-elles pas ? Nous disposons de règles WAF, de tableaux de bord SIEM et de contrôles PCI. Pourtant, ces couches de sécurité ont toujours un angle mort pour les attaques côté client, côté navigateur, comme Magecart.
1. Les WAF, SIEM et données de transaction passent à côté des attaques Magecart
La plupart des outils de sécurité web sont conçus pour protéger l'activité côté serveur ou surveiller l'infrastructure de l'entreprise, pas le navigateur des utilisateurs. Un WAF inspecte le trafic vers vos applications, mais ne voit pas ce que le navigateur envoie directement à d'autres domaines. Un SIEM affiche les journaux serveur et infrastructure, mais n'enregistre pas les appels sortants supplémentaires du navigateur vers des points de terminaison malveillants.
L'analyse des données de transaction pour détecter la fraude ne révèle aucune trace d'une attaque Magecart, car le flux d'achat légitime se déroule normalement. Le skimmer copie les détails de la carte dans le navigateur tandis que le backend voit une transaction propre et autorisée, sans anomalie.
Des attaquants expérimentés peuvent intercepter des valeurs sensibles au niveau du DOM avant qu'elles ne soient jamais envoyées à vos serveurs, neutralisant ainsi vos systèmes d'alerte.
2. L'absence de visibilité sur les scripts tiers accroît le risque Magecart
Avoir une visibilité complète sur les scripts tiers est un défi de taille. Quels scripts s'exécutent ? Sont-ils autorisés à s'exécuter sur un formulaire de paiement ou une page de connexion ? Qui surveille leur comportement et leurs évolutions dans le temps ? Des questions très basiques auxquelles de nombreuses organisations peinent à répondre lorsque personne ne prend vraiment en charge la chaîne d'approvisionnement côté client.
Les développeurs web ont un contrôle limité sur ces scripts, car ils sont gérés et hébergés par des fournisseurs externes. Lorsque la propriété change ou que des employés quittent l'entreprise, les scripts tiers ou les bibliothèques JavaScript peuvent ne plus être mis à jour, et une vulnérabilité dans l'un de ces scripts tiers peut devenir un risque de sécurité.
C'est précisément le point d'entrée qu'exploitent les attaques Magecart. Compromettre un script ou une bibliothèque tiers largement utilisé permet de le transformer en une attaque de chaîne d'approvisionnement à grande échelle touchant tous les sites qui l'utilisent.
3. Un problème côté client nécessite une défense côté client
C'est le problème fondamental avec Magecart : la plupart des entreprises n'ont aucune visibilité réelle sur ce qui se passe dans le navigateur. Les tableaux de bord de sécurité côté serveur ne montrent pas vers quels domaines le navigateur envoie des requêtes lors du paiement, même lorsqu'il s'agit d'appels cross-origin (CORS).
Ils n'alertent pas lorsqu'un nouveau domaine sortant apparaît sur un formulaire de paiement. Et ils n'envoient pas d'avertissement en cas de violation de la Content Security Policy (connect-src) lorsqu'un script tente d'exfiltrer des données vers un point de terminaison inattendu.
4. La fraude n'est découverte que plus tard, bien plus tard
L'un des aspects les plus dommageables d'une attaque Magecart est qu'elle est rarement détectée par l'organisation qui a réellement été compromise. Dans la plupart des cas, les premiers signes d'alerte proviennent des banques, des émetteurs de cartes ou des clients. Au moment où ces signalements externes remontent, le skimmer a déjà collecté un volume significatif de données de titulaires de cartes.
Comment prévenir les attaques Magecart
Les principes fondamentaux de la prévention Magecart sont simples : gardez votre tunnel de paiement aussi épuré et minimal que possible, maîtrisez les scripts qui s'y exécutent et ajoutez des contrôles côté navigateur avec une surveillance continue 24h/24 et 7j/7. Les étapes logiques suivantes vous aideront à mettre en œuvre des mesures de prévention pour réduire votre exposition à Magecart.
1. N'exécutez que les scripts nécessaires sur les pages de connexion et de paiement
Sur les pages de connexion et de paiement, chaque script supplémentaire représente un risque. Ces pages ne devraient charger que l'UX de base et ce qui est strictement nécessaire à l'authentification et au paiement. Sans hésitation, supprimez les scripts marketing, d'analyse, les widgets de chat, etc. des pages de connexion et de paiement.
De préférence, isolez le tunnel de paiement en utilisant un template minimaliste, voire un sous-domaine dédié avec uniquement les entrées tierces nécessaires. Ce faisant, vous limitez votre surface d'attaque et les opportunités pour le code Magecart de dissimuler ses traces. De plus, la remédiation sera beaucoup plus simple en cas de problème.
2. Utilisez cside pour la gouvernance des scripts tiers
Créez un inventaire des scripts pour avoir une vue claire de quels scripts s'exécutent où et ce qu'ils font réellement. Les pages sensibles, notamment la connexion et le paiement, ne devraient servir que des scripts tiers approuvés avec une justification.
Définissez ensuite un processus de gestion des changements pour préciser qui est autorisé à modifier les scripts et les conteneurs de gestionnaires de balises. Vous pouvez également exiger des prévisualisations et des approbations avant que les modifications ne soient mises en production. En parallèle, appliquez une gouvernance stricte des fournisseurs et intégrez la sécurité des scripts et la gestion des incidents dans les contrats et l'onboarding des prestataires externes.
Un outil de gouvernance des scripts tiers peut automatiser ces éléments instantanément grâce à un tableau de bord qui associe chaque script à un fournisseur et génère automatiquement des descriptions de ce que fait chaque script.
3. Utilisez les contrôles navigateur : CSP et SRI
Une Content Security Policy (CSP) vous permet de définir depuis quels domaines les scripts sont autorisés à se charger (script-src) et vers quels domaines le navigateur est autorisé à envoyer des données (connect-src).
script-src doit être restreint aux domaines de confiance et connect-src ne doit autoriser que les points de terminaison nécessaires au paiement, plutôt que d'autoriser toutes les destinations.
L'activation d'une CSP facilite également le signalement des violations de politique, notamment sur les pages de connexion et de paiement. Les tentatives d'injection de scripts inattendus et d'exfiltration seront ainsi révélées. Pour les bibliothèques tierces statiques, utilisez la Subresource Integrity (SRI) pour renforcer l'intégrité, mais considérez-la comme une couche parmi d'autres dans votre défense, et non comme la solution miracle.
4. Utilisez cside pour la surveillance Magecart
Face à Magecart, vous avez besoin d'une visibilité dans le navigateur. Une surveillance côté client automatisée, continue et 24h/24, révèle quels scripts s'exécutent et les comportements suspects qui signalent une activité Magecart. Un outil de prévention Magecart cartographie tous les scripts de votre site et utilise un moteur assisté par IA pour détecter les signaux d'alerte à partir d'une variété de points de données.
cside aide les marchands à identifier et stopper :
- Les attaques de chaîne d'approvisionnement JavaScript tiers
- Les scripts tiers malveillants ou altérés
- Les scripts mal configurés qui fuient des données sensibles
- Magecart, l'e-skimming, le formjacking et les skimmers associés
cside est validé pour les exigences côté client de la PCI DSS 4.0.1 et est utilisé par les équipes conformité pour prévenir les violations RGPD, CCPA et autres violations de confidentialité causées par des scripts tiers à risque.
Auto-évaluation rapide de votre préparation face à Magecart
Êtes-vous prêt à contrer les attaques de type Magecart ? Oui/Non
- Nos pages de paiement et de connexion ne chargent que des scripts dont nous connaissons la finalité et le comportement attendu
- Nous disposons d'une liste à jour de tous les scripts, internes et tiers, qui s'exécutent sur notre page de paiement
- Les scripts marketing, d'analyse, de test A/B et les widgets de chat sont surveillés pour s'assurer qu'ils ne collectent pas plus de données que nécessaire
- Les modifications apportées aux scripts « de confiance » tels que les conteneurs de gestionnaires de balises…
- Nous vérifions l'intégrité des scripts via un outil de sécurité côté client ou un autre mécanisme (tel que la Subresource Integrity)
- Notre surveillance côté client indique vers quels domaines les données collectées par les scripts tiers sont envoyées
- Nous disposons d'un mécanisme pour bloquer les scripts publiquement identifiés comme compromis
Les plus grandes attaques Magecart de ces dernières années
Notre rapport sur les menaces côté client 2025 a identifié plus de 72 000 sites web touchés par des attaques côté client. Ces attaques suivent le même schéma que les plus grandes attaques Magecart de ces dernières années : quelques lignes de JavaScript malveillant compromettent des millions d'utilisateurs avant que quiconque ne s'en aperçoive. Voici un résumé rapide des cas les plus marquants.
- Ticketmaster (2018) – Script de chatbot compromisDes attaquants ont injecté du code de skimming dans un chatbot tiers hébergé par Inbenta Technologies. Chaque chargement de page exécutait le script malveillant, exposant les données de paiement et personnelles d'environ 9,4 millions de clients pendant quatre mois. L'incident a entraîné des amendes réglementaires et des règlements dans le cadre d'actions collectives.
- British Airways (2018) – 22 lignes de JavaScript malveillantDes attaquants ont obtenu un accès via des identifiants tiers compromis et ont inséré seulement 22 lignes de code de skimmer dans une bibliothèque utilisée sur la page de paiement de BA. Les données étaient exfiltrées vers un domaine sosie (« baways.com »), affectant environ 400 000 clients. BA a fait face à des dizaines de millions d'euros d'amendes RGPD et à des années de contentieux.
- Newegg (2019) – Script injecté sur la page de paiementDes attaquants ont obtenu un accès en écriture au serveur de paiement de Newegg et ont ajouté un petit skimmer au bouton de paiement. Lorsque les clients validaient leur paiement, les données de carte étaient envoyées vers un faux domaine d'analyse (« neweggstats.com »), compromettant numéros de carte, CVV et PII pendant plus d'un mois avant détection.
FAQ
Comment savoir si mon site est infecté par Magecart ou un e-skimmer ?
Les attaques Magecart sont difficiles à détecter car le tunnel de paiement continue de fonctionner normalement et les outils côté serveur ne voient rien d'inhabituel. La seule méthode fiable est la surveillance côté client avec un outil comme cside, qui inspecte les scripts s'exécutant dans le navigateur et signale les modifications de code suspectes ou les transferts de données sortants.
Les attaques Magecart peuvent-elles survenir même si j'utilise un prestataire de paiement comme Stripe ou PayPal ?
Oui. Si vos champs de paiement sont hébergés sur votre propre site (même en utilisant un prestataire de paiement tiers), les scripts tiers présents sur votre page peuvent toujours accéder à ce que les utilisateurs saisissent dans ces champs. Si votre site redirige entièrement les clients vers le domaine du prestataire de paiement (par exemple, checkout.stripe.com), Magecart ne peut pas y collecter les données de carte. En revanche, d'autres informations sensibles présentes sur votre site — identifiants de connexion, données KYC ou informations de compte — peuvent toujours être aspirées si des scripts malveillants sont présents.
Une attaque Magecart peut-elle survenir si je tokenise ou chiffre les données de carte bancaire ?
Oui. La tokenisation et le chiffrement n'interviennent qu'après la validation du paiement par le client, mais Magecart vole les données au moment où l'utilisateur les saisit. Même les flux entièrement tokenisés ou chiffrés restent vulnérables au skimming si des scripts malveillants s'exécutent sur la page.
