Skimmer Magecart sur Magento : comment le repérer

Q: Qu'est-ce que Magecart ?

C'est le nom donné à plusieurs groupes criminels qui volent les cartes bancaires sur les boutiques en ligne, et par extension à leur méthode : un script ajouté à la page de paiement copie la carte pendant que le client la tape. Toutes les plateformes de commerce en ligne peuvent être visées.

Q: Un paiement par iframe ou par redirection me protège-t-il d'un skimmer ?

Il réduit le risque, car les champs de carte ne sont plus sur votre page. Mais la page qui entoure le formulaire reste la vôtre, et un script peut y voler les autres données du client : nom, adresse, e-mail, mot de passe. Le PCI SSC demande aux marchands qui intègrent le formulaire d'un prestataire de confirmer que leur site n'est pas vulnérable aux attaques par script.

Q: Ma banque me signale un point de compromission commun. Que faire ?

Prenez-le au sérieux, même si vous ne voyez rien d'anormal. Faites chercher un skimmer par la personne qui gère le serveur, gardez toutes les traces, répondez à la banque dans les délais qu'elle vous donne et vérifiez si vous devez notifier la CNIL.

Q: Un scanner en ligne détecte-t-il un skimmer ?

Parfois. Un scanner externe ne voit que ce que la page lui montre à l'instant où il passe, et un skimmer se déclenche souvent au moment où le client valide son paiement, une page qu'un scanner n'atteint pas toujours. Il complète une surveillance des fichiers et de la base, il ne la remplace pas.

Q: Dois-je prévenir mes clients ?

Si leurs cartes ou leurs données ont pu être volées et que le risque pour eux est élevé, oui : le RGPD l'exige dans les meilleurs délais, sauf exceptions. Le prestataire de paiement et la CNIL peuvent vous aider à décider.

En bref

Un skimmer copie la carte bancaire dans le navigateur du client, au moment où il la tape. Votre boutique n’a pas besoin d’enregistrer les cartes pour être touchée.
Dans Magento, il se cache le plus souvent dans un bloc de contenu, dans les scripts de l’en-tête ou du pied de page, ou dans un fichier JavaScript de la boutique.
Comme ni vous ni vos clients ne voyez rien, l’alerte vient souvent de la banque ou du prestataire de paiement, qui voit des cartes fraudées après un achat chez vous.
Si vous en trouvez un : prévenez votre prestataire de paiement, gardez une copie du script, faites chercher l’entrée de l’attaquant et pensez à la CNIL, 72 heures au plus tard après la découverte si possible.

Sommaire

Un skimmer Magecart, en clair

Dans un magasin, un skimmer est un faux lecteur posé sur le terminal de paiement. Sur une boutique en ligne, c’est la même idée, en code : un script ajouté à la page lit les champs du formulaire de paiement et les envoie ailleurs. Selon les cas, il prend le numéro de carte, la date, le cryptogramme, mais aussi le nom, l’adresse, l’e-mail ou le mot de passe du client.

Magecart est le nom donné par la presse et des chercheurs en sécurité à plusieurs groupes criminels qui pratiquent ce vol, et par extension à l’attaque elle-même. Le PCI Security Standards Council, qui écrit les règles de sécurité des cartes bancaires, la décrit comme très difficile à détecter : la carte est copiée pendant l’achat, sans que le marchand ni le client s’en aperçoivent.

Pour poser son script, l’attaquant doit d’abord entrer. Le PCI SSC cite les extensions vulnérables, les mots de passe devinés ou réutilisés, l’hameçonnage, et les services tiers compromis : un script de publicité, de discussion en ligne ou d’avis clients, modifié chez son éditeur, touche toutes les boutiques qui le chargent.

Où un skimmer se cache dans Magento

Un skimmer doit être chargé sur la page de paiement. Dans Magento, cela laisse quelques cachettes classiques. Les chemins de menus ci-dessous sont ceux d’une administration en français ; les libellés peuvent varier légèrement selon le pack de langue installé.

Les blocs, les pages et les widgets

Contenu > Éléments > Blocs, Pages et Widgets. Un bloc peut contenir du HTML, donc un script, et s’afficher sur toutes les pages, paiement compris. Un bloc créé ou modifié récemment, au nom anodin, mérite un coup d’œil.

Les scripts de l’en-tête et du pied de page

Contenu > Design > Configuration, puis la vue magasin. Deux champs acceptent des scripts :

En-tête HTML > Scripts et feuilles de Style, ajouté avant la fin de l’en-tête de chaque page ;
Bas de page > Code HTML divers, ajouté en bas de chaque page.

On y trouve normalement vos outils de mesure d’audience ou de discussion. Adobe recommande de relire ces champs à chaque niveau (site, boutique, vue magasin) et de retirer tout JavaScript que vous ne reconnaissez pas.

Les fichiers JavaScript de la boutique

Le dossier pub/static contient le JavaScript envoyé à chaque visiteur. Il est régénéré à chaque déploiement. Un fichier de ce dossier modifié entre deux déploiements, c’est anormal. Le skimmer peut aussi se trouver dans le code du thème ou d’une extension.

Ailleurs dans la base de données

Magento range beaucoup de réglages dans la base. Un script peut se glisser dans n’importe quelle valeur qui finit affichée sur une page. C’est pourquoi la recherche en base, plus bas, ne se limite pas aux deux champs de l’en-tête et du pied de page.

Les signes d’un skimmer de carte bancaire sur votre boutique

Votre banque ou votre prestataire de paiement vous contacte : plusieurs cartes fraudées ont en commun un achat chez vous. Comme le vol est invisible pour le marchand, c’est souvent par là qu’il se découvre.
Des clients se plaignent d’une fraude sur leur carte peu après une commande.
Le formulaire de paiement change : un champ de carte en double, une étape en plus, un paiement refusé puis accepté à la seconde tentative.
Un script inconnu apparaît dans un bloc ou dans les champs de l’en-tête et du pied de page.
La page de paiement contacte un domaine inconnu, que la personne qui gère le site ne sait pas expliquer.

Faites le tour des deux champs de Contenu > Design > Configuration et des blocs récents. Pour chaque script, demandez-vous qui l’a ajouté et à quoi il sert. Si personne ne le sait, ne le supprimez pas tout de suite : lisez la suite.

Skimmer découvert sur Magento : que faire

Gardez une copie du script avant de le retirer. Copiez son contenu, notez où il était (bloc, champ, fichier) et faites une capture d’écran. Adobe parle de mettre le code suspect en quarantaine : on le sort du site, on ne le détruit pas. Ensuite seulement, retirez-le ou passez la boutique en maintenance pour arrêter le vol.
Prévenez votre prestataire de paiement ou votre banque, sans attendre la fin de l’enquête. Le guide de Visa demande de prévenir la banque du commerçant immédiatement, puis de lui remettre un rapport d’incident sous trois jours ouvrés. Visa et la banque décident ensuite si une enquête indépendante est nécessaire.
Pensez à la CNIL. Une carte bancaire, un nom, une adresse sont des données personnelles. Le RGPD demande de notifier la violation dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance. Si le risque pour vos clients est élevé, il faut aussi les prévenir.
Faites chercher par où l’attaquant est entré. Retirer le script ne suffit pas : un compte administrateur créé par l’attaquant, une faille non corrigée ou une porte dérobée lui permettent de le remettre. Le PCI SSC le souligne : si la faille n’est pas corrigée, ou si une partie du code de l’attaquant reste, l’infection revient. Toute la marche à suivre est dans notre article Magento 2 piraté : les signes et la marche à suivre.
Portez plainte, avant de réinstaller le serveur, comme le conseille Cybermalveillance.gouv.fr.

Message à votre hébergeur ou à votre agence

Bonjour,

Nous soupçonnons un skimmer de carte bancaire sur notre boutique Magento : [décrivez ce que vous avez vu, par exemple l’alerte de la banque ou le script trouvé, et où].

Pouvez-vous, en urgence :

conserver une copie des logs du serveur et de Magento, sans rien supprimer ;
chercher les scripts ajoutés dans les blocs CMS, la configuration HTML et les fichiers de pub/static ;
nous dire depuis quand ils sont présents et par où ils ont été ajoutés ;
nous indiquer les sauvegardes disponibles et leurs dates.

Merci de nous répondre au plus vite.

Vous gérez le serveur : chercher un skimmer dans Magento

Tout ce qui suit est en lecture seule. Les requêtes se lancent dans le client MySQL ou MariaDB, connecté à la base de Magento (les accès sont dans app/etc/env.php). Si la base utilise un préfixe de tables, ajoutez-le aux noms.

Les valeurs de configuration qui contiennent un script, plus les deux champs de l’en-tête et du pied de page :

Requête SQL · Configuration : scripts et iframes

SELECT config_id, scope, scope_id, path, updated_atFROM core_config_dataWHERE path IN ('design/head/includes', 'design/footer/absolute_footer') OR value LIKE '%<script%' OR value LIKE '%<iframe%';

design/head/includes est le champ Scripts et feuilles de Style, design/footer/absolute_footer le champ Code HTML divers. Regardez la colonne updated_at, puis lisez la valeur des lignes suspectes.
Les blocs et les pages qui contiennent un script :

Requête SQL · Blocs et pages CMS : scripts et iframes

SELECT block_id, identifier, title, is_active, update_timeFROM cms_blockWHERE content LIKE '%<script%' OR content LIKE '%<iframe%'ORDER BY update_time DESC;SELECT page_id, identifier, title, is_active, update_timeFROM cms_pageWHERE content LIKE '%<script%' OR content LIKE '%<iframe%'ORDER BY update_time DESC;
Les fichiers de pub/static plus récents que le dernier déploiement. Magento réécrit pub/static/deployed_version.txt à chaque déploiement du contenu statique. Un fichier plus récent que lui a été changé après :

Terminal

find /var/www/boutique/pub/static -type f -newer /var/www/boutique/pub/static/deployed_version.txt -print

Si la fusion du JavaScript est activée, les fichiers de pub/static/_cache/merged sont recréés après chaque vidage du cache : ils peuvent sortir sans être suspects. Les autres méritent une explication.
Le code de la boutique, si elle est versionnée avec Git :

Terminal, depuis le dossier de Magento

git status --short

Réduire le risque d’un skimmer sur Magento

Passez à Magento 2.4.7 ou plus récent. Adobe y a ajouté, pour répondre à PCI DSS 4.0, une vérification d’intégrité des scripts (SRI) et une politique de sécurité du contenu (CSP) en mode restrictif sur les pages de paiement. Un script non autorisé y est bloqué par le navigateur. Les autres pages restent en mode « rapport » par défaut.
Appliquez les correctifs de sécurité dès leur sortie : voir les correctifs de sécurité Adobe pour Magento.
Limitez les scripts tiers sur la page de paiement. Le PCI SSC recommande de ne pas y charger de JavaScript hébergé ailleurs et, quand c’est possible, d’héberger soi-même une copie des scripts tiers.
Protégez l’administration : authentification à deux facteurs, un compte par personne, comptes inutiles supprimés. Voir repérer un compte administrateur suspect.
Connaissez vos obligations PCI DSS. Depuis le 31 mars 2025, les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0 sont obligatoires : les scripts de la page de paiement doivent être autorisés, leur intégrité vérifiée, et toute modification détectée. Votre prestataire de paiement vous dit quel questionnaire (SAQ) vous concerne.

Tocsin24 surveille les cachettes habituelles des skimmers

Tocsin24 relève les blocs et pages CMS et les champs HTML de la configuration de votre boutique Magento. Il ouvre un incident critique dès qu’un script, une iframe ou un domaine externe y apparaît. En mode production, il surveille aussi les fichiers JavaScript de pub/static, ceux que reçoit chaque visiteur : un fichier modifié hors déploiement est un incident critique, et Tocsin24 lit ces fichiers pour y chercher des motifs de skimmer, comme des champs de carte envoyés vers un domaine externe. Le code de la boutique est contrôlé toutes les heures.

Tocsin24 n’est ni un pare-feu ni un nettoyage automatique. Il ne voit pas un script tiers modifié chez son éditeur, ni les widgets. Il vous prévient vite, et l’intervention reste humaine, avec l’intervention après compromission.

Essayer gratuitement Voir la surveillance Magento 2

Critique Ouvert #231

Fichier statique modifié hors déploiement

Sécurité · détecté le 22 octobre 2026 à 02:43 · 1 occurrence

Traiter l'incident

Fichiers concernés1 Relevé du 22 octobre 2026 à 02:43

JavaScript, templates ou JSON de pub/static modifiés sans redéploiement du contenu statique : ce que reçoit chaque visiteur a changé.

Fichier	Changement
pub/static/frontend/Magento/luma/fr_FR/Magento_Checkout/js/view/payment/default.js	MModifié

« Légitime » valide tout le lot.

Preuve de chaque passage dans « Historique et preuves ».

Critique Ouvert #232

Modifié — bloc CMS : footer-links

Sécurité · détecté le 22 octobre 2026 à 02:12 · 1 occurrence

Traiter l'incident

Contenu et code en cause Relevé du 22 octobre 2026 à 02:12

Fragments suspects relevés dans le contenu (les ressources chargées depuis la boutique sont écartées). Le code est montré comme du texte, jamais exécuté.

Type: Bloc CMS
Identifiant: footer-links
Titre: Liens du pied de page
Actif: oui
Vues magasin: Toutes
Taille: 1,9 Ko
Hôtes externes: cdn-stats.example.com
Créé le: 4 mars 2025 10:20

Information	Avant après	Relevé
Contenu	modifié	22 oct. 02:12
Taille	1,2 Ko1,9 Ko	22 oct. 02:12
Hôtes externes	—cdn-stats.example.com	22 oct. 02:12

Script · cdn-stats.example.com

<script src="https://cdn-stats.example.com/s.js"></script>

Preuve détaillée dans « Historique et preuves ».

Écrans de l’application avec des valeurs d’exemple.

Questions fréquentes

Qu’est-ce que Magecart ?

C’est le nom donné à plusieurs groupes criminels qui volent les cartes bancaires sur les boutiques en ligne, et par extension à leur méthode : un script ajouté à la page de paiement copie la carte pendant que le client la tape. Toutes les plateformes de commerce en ligne peuvent être visées.

Un paiement par iframe ou par redirection me protège-t-il d’un skimmer ?

Il réduit le risque, car les champs de carte ne sont plus sur votre page. Mais la page qui entoure le formulaire reste la vôtre, et un script peut y voler les autres données du client : nom, adresse, e-mail, mot de passe. Le PCI SSC demande aux marchands qui intègrent le formulaire d’un prestataire de confirmer que leur site n’est pas vulnérable aux attaques par script.

Ma banque me signale un point de compromission commun. Que faire ?

Prenez-le au sérieux, même si vous ne voyez rien d’anormal. Faites chercher un skimmer par la personne qui gère le serveur, gardez toutes les traces, répondez à la banque dans les délais qu’elle vous donne et vérifiez si vous devez notifier la CNIL.

Un scanner en ligne détecte-t-il un skimmer ?

Parfois. Un scanner externe ne voit que ce que la page lui montre à l’instant où il passe, et un skimmer se déclenche souvent au moment où le client valide son paiement, une page qu’un scanner n’atteint pas toujours. Il complète une surveillance des fichiers et de la base, il ne la remplace pas.

Dois-je prévenir mes clients ?

Si leurs cartes ou leurs données ont pu être volées et que le risque pour eux est élevé, oui : le RGPD l’exige dans les meilleurs délais, sauf exceptions. Le prestataire de paiement et la CNIL peuvent vous aider à décider.

Cédric Michel

Cédric développe des boutiques Magento depuis 18 ans et détient la certification Adobe Commerce Developer Expert. Il a créé Tocsin24 pour surveiller la sécurité et la santé des boutiques Magento 2 et des sites WordPress.

Adobe Commerce Developer Expert
Vérifier la certification sur le site d’Adobe

Skimmer de carte bancaire (Magecart) sur Magento : comment le repérer