Skimming Magecart : quand un script malveillant vole les cartes bancaires de votre client

Contrairement au crash de site que tout le monde voit, le skimming web — souvent regroupé sous le nom de Magecart — est conçu pour rester invisible le plus longtemps possible. Le principe : un attaquant parvient à injecter quelques lignes de JavaScript dans la page de paiement. Ce script écoute la saisie de l'acheteur et, dès qu'il tape son numéro de carte, son cryptogramme et sa date d'expiration, il les recopie et les envoie discrètement vers un serveur contrôlé par le pirate.

Le tunnel d'achat continue de fonctionner parfaitement. Le client paie, reçoit sa confirmation, est livré. Rien d'anormal en apparence. La fuite peut durer des semaines avant d'être détectée — généralement lorsque les banques constatent une vague de fraudes ayant un point commun : toutes les victimes ont acheté sur le même site.

La technique est redoutable car elle ne laisse quasiment aucune trace côté serveur : le code malveillant s'exécute dans le navigateur de l'acheteur, pas sur l'infrastructure du marchand. Les scanners de sécurité classiques, qui surveillent les fichiers du serveur, ne voient rien. Le script est souvent obfusqué, parfois chargé conditionnellement (uniquement sur la page de paiement, uniquement pour les vrais clients et jamais pour les robots d'analyse), ce qui le rend encore plus difficile à repérer lors d'un audit ponctuel.

Pour l'intégrateur, c'est le pire des scénarios : le sinistre est silencieux, durable et touche des données ultra-sensibles. Quand il éclate, le préjudice est déjà massif, et la première question que tout le monde se pose est : qui avait la main sur le code de la page de paiement ?

La question décisive est : par où le script est-il entré ? Dans une part importante des cas, le vecteur n'est pas le serveur du marchand directement, mais un composant que vous, intégrateur, avez ajouté au site.

• Un module Prestashop ou une app Shopify téléchargé sur une place de marché et compromis à la source.
• Une dépendance JavaScript (bibliothèque de tracking, widget d'avis, chat) chargée depuis un CDN tiers piraté.
• Un thème acheté contenant déjà du code obfusqué malveillant.
• Une console d'administration dont les accès, mal sécurisés lors de l'intégration, ont permis l'injection.

Le marchand, lui, raisonne simplement : « C'est vous qui avez installé ce module, c'est vous qui aviez la main sur le code, donc c'est votre faute. » Juridiquement, votre responsabilité de professionnel peut effectivement être recherchée au titre de votre devoir de conseil et de vigilance : avez-vous vérifié la provenance du composant ? Maintenu les dépendances à jour ? Mis en place une politique de sécurité des contenus (CSP) limitant les scripts autorisés ?

Vous n'êtes pas l'auteur du piratage, mais en tant qu'intégrateur, vous êtes celui qui a la maîtrise technique du périmètre. C'est suffisant pour que votre responsabilité soit discutée.

Une fuite de données bancaires et d'identité est une violation de données personnelles au sens du RGPD. Elle enclenche un mécanisme strict et chronométré qui dépasse largement le cadre technique.

1. Notification à la CNIL sous 72 heures à compter de la prise de connaissance de la violation, dès lors qu'elle présente un risque pour les personnes — ce qui est systématique avec des données bancaires.
2. Information directe des personnes concernées lorsque le risque est élevé : il faut prévenir tous les acheteurs dont la carte a pu être copiée.
3. Documentation de la violation dans un registre interne, que la CNIL peut exiger lors d'un contrôle.

Le marchand est le responsable de traitement, donc le premier visé par la CNIL. Mais s'il démontre que la faille provient de votre prestation, il se retournera contre vous pour récupérer le coût des sanctions, des notifications de masse et de la perte de clientèle. Le détail des enjeux figure sur notre page assurance cyber.

Une RC Pro couvre votre faute professionnelle et les dommages immatériels causés au marchand. Mais un incident de skimming génère une famille de coûts spécifiques que les contrats de responsabilité classiques excluent presque toujours :

• L'analyse forensique pour identifier le point d'entrée et la durée de la compromission.
• Les frais de notification à la CNIL et l'information de potentiellement des milliers d'acheteurs.
• La gestion de crise et la communication pour limiter l'atteinte à la réputation.
• Les frais de remédiation : nettoyage du code, audit complet, reconstruction des accès.
• La prise en charge des réclamations des clients finaux victimes de fraude.

C'est exactement le périmètre d'une garantie Cyber. Pour un développeur e-commerce, elle n'est pas une option de confort mais une protection structurelle, car les sites marchands sont des cibles privilégiées. Idéalement, la garantie Cyber est adossée à votre RC Pro pour que la faute professionnelle et ses conséquences cyber soient traitées dans un seul et même contrat, sans zone grise entre deux assureurs.

Pour mesurer pourquoi une garantie dédiée est indispensable, il faut décomposer ce que coûte réellement un incident. Le numéro de carte volé n'est que le point de départ : c'est la cascade de conséquences qui fait exploser la facture, souvent étalée sur plusieurs mois.

Le marchand additionne tous ces postes et, s'il établit que la faille vient de votre prestation, vous adresse une réclamation globale. Sans garantie Cyber, c'est vous qui financez l'analyse forensique et la remédiation sur vos fonds propres, avant même de savoir si votre responsabilité sera retenue. La garantie Cyber, elle, déclenche immédiatement la prise en charge de la gestion de crise, ce qui est crucial : dans ce type d'incident, la vitesse de réaction conditionne directement l'ampleur du préjudice final.

L'assurance intervient après le sinistre. En amont, quelques pratiques d'hygiène réduisent fortement votre exposition et renforcent votre position en cas de litige.

• Tracer la provenance de chaque composant tiers installé : éditeur, version, source de téléchargement. C'est la preuve de votre diligence.
• Mettre à jour les dépendances et surveiller les vulnérabilités connues des modules et bibliothèques utilisés.
• Déployer une politique de sécurité des contenus (CSP) qui restreint les domaines autorisés à exécuter du JavaScript sur la page de paiement.
• Limiter le périmètre de saisie des données bancaires en privilégiant les solutions de paiement hébergées (redirection ou iframe du prestataire de paiement), qui isolent la carte du DOM de la page.
• Documenter par écrit vos recommandations de sécurité auprès du marchand, surtout s'il les refuse pour des raisons de budget.

Pour un panorama complet des risques de votre activité, consultez la page métier dédiée. Le skimming est un risque structurel du e-commerce : on ne l'élimine pas, on le maîtrise et on s'assure contre ses conséquences.