Paiement par carte : comment les pirates volent les données bancaires des boutiques en ligne

Quand un client paie par carte sur votre boutique, il vous fait confiance. Il suppose que ses données bancaires ne tomberont pas entre de mauvaises mains. La plupart du temps, c'est le cas. Mais il existe une catégorie d'attaques conçue précisément pour intercepter ces données au moment du paiement, sans que ni le client ni le marchand ne s'en aperçoivent.

Voici comment ces attaques fonctionnent, ce qui s'est réellement passé sur des boutiques PrestaShop, et ce que vous pouvez mettre en place. Pas de panique : ces risques sont connus, et les parades aussi.

Le principe : un « skimmer » caché dans la boutique

Dans le commerce physique, un skimmer est un faux lecteur posé sur un distributeur de billets pour copier les cartes. Sur Internet, le principe est le même, en version logicielle. On parle de web skimming, d'e-skimming ou d'attaque « Magecart » (du nom de Magento, une plateforme très visée à l'origine). Toutes les plateformes sont concernées.

Concrètement, le pirate commence par prendre le contrôle d'une partie du site. Il y ajoute ensuite un petit programme discret. Selon la société spécialisée Sansec, ce programme fonctionne « de façon transparente » : ni le client ni le marchand ne remarquent de changement visible.

On rencontre principalement trois scénarios :

• Le script espion. Un code malveillant est ajouté aux pages de la boutique. Il enregistre ce que le client tape (nom, adresse, numéro de carte) et l'envoie discrètement au pirate.
• Le faux formulaire de paiement. C'est le scénario le plus courant sur les boutiques dont le paiement se fait chez la banque. Le pirate ajoute dans le tunnel de commande un formulaire de carte bancaire qui imite celui de votre prestataire. Le client remplit le faux formulaire, puis il est redirigé vers le vrai. Sansec parle de « double saisie » : beaucoup de clients pensent à un simple bug, saisissent leur carte une seconde fois, et finalisent leur commande sans se douter de rien.
• Le vol de la base clients. Sans même toucher au paiement, une faille peut permettre de copier la base de données : noms, e-mails, adresses, historique de commandes. Ces données servent ensuite à des campagnes d'hameçonnage très crédibles.

Ce qui s'est passé concrètement sur PrestaShop

L'alerte officielle de juillet 2022

Le 22 juillet 2022, l'équipe PrestaShop a publié une alerte de sécurité majeure. Des pirates utilisaient une chaîne de failles pour injecter du code dans les boutiques, puis ajoutaient un faux formulaire de paiement sur la page de commande. PrestaShop prévenait que les clients pouvaient y saisir leurs informations de carte.

La faille du cœur de PrestaShop exploitée dans cette attaque porte le numéro CVE-2022-31181. Elle concerne les versions à partir de la 1.6.0.10 et a été corrigée dans la version 1.7.8.7, publiée le 25 juillet 2022. Elle était classée critique (9,8 sur 10). Point important : pour être exploitée, elle nécessitait une autre faille, de type « injection SQL », présente dans le cœur ou… dans un module.

Les failles des modules tiers

C'est souvent là que se situe le maillon faible. Une boutique PrestaShop compte facilement des dizaines de modules, de provenances diverses. Chacun est une porte d'entrée potentielle s'il contient une erreur de programmation.

Le collectif Friends-Of-Presta recense publiquement ces failles sur son site security.friendsofpresta.org. Un exemple parmi d'autres : en juin 2024, il a publié un avis (CVE-2024-36680) concernant un module de connexion via Facebook. Selon Friends-Of-Presta, cette faille était « activement utilisée pour déployer un skimmer afin de voler massivement des cartes bancaires ».

Une nouvelle alerte en 2026

Début 2026, PrestaShop a de nouveau alerté les marchands. Un script malveillant, ajouté directement dans un fichier du thème (_partials/head.tpl), remplaçait les boutons de paiement par de faux boutons menant à un faux formulaire. En février 2026, Sansec a décrit ce type de skimmer sur la boutique PrestaShop d'une grande enseigne de distribution. Détail notable : ce code se désactivait quand il détectait un administrateur connecté. Le marchand qui testait son propre tunnel de commande ne voyait donc rien.

Comment les pirates choisissent leurs cibles

Dans l'immense majorité des cas, personne ne vous « choisit » personnellement. Des outils automatisés parcourent Internet en continu et repèrent les boutiques sur une version ancienne, ou équipées d'un module dont une faille est connue. L'attaque est ensuite lancée en série.

L'intelligence artificielle accélère ce travail. Dans sa synthèse du 4 février 2026, l'ANSSI (l'agence nationale de cybersécurité) indique que l'IA générative sert aux attaquants les plus avancés d'outil « de gain de performance et de passage à l'échelle ». Sansec note de son côté qu'elle permet de produire en quelques minutes de faux formulaires de paiement adaptés à n'importe quelle langue et n'importe quel style. L'ANSSI précise toutefois qu'aucune IA n'a, à ce jour, mené seule une attaque de bout en bout.

Pourquoi c'est grave pour le marchand

• Vos clients sont fraudés. Ils voient apparaître des achats inconnus sur leur relevé, parfois des semaines plus tard.
• Les réclamations arrivent. Contestations de paiement, e-mails mécontents, avis négatifs.
• La confiance s'effrite. Un client fraudé revient rarement.
• Votre prestataire de paiement peut réagir. Les banques et prestataires surveillent les fraudes. En cas de doute, ils peuvent demander des explications, voire suspendre l'encaissement.
• Vous avez des obligations légales. Une fuite de données personnelles est une « violation de données » au sens du RGPD. L'article 33 impose de la notifier à la CNIL « dans les meilleurs délais et, si possible, 72 heures au plus tard » après en avoir pris connaissance, sauf si elle ne présente pas de risque pour les personnes. Si le risque est élevé, l'article 34 impose aussi d'informer les clients concernés. Dans tous les cas, la CNIL demande de documenter l'incident en interne.

Un mot sur PCI DSS : c'est la norme de sécurité des cartes bancaires. Elle s'applique à toute organisation qui stocke, traite ou transmet des données de cartes, ou dont l'activité peut affecter leur sécurité. C'est votre banque (l'« acquéreur ») qui fixe la manière d'en justifier. Faire saisir la carte chez votre prestataire allège ces exigences, sans les supprimer.

Les signes qui doivent vous alerter

Aucun de ces signes ne prouve à lui seul une attaque. Mais chacun mérite une vérification :

• Le formulaire de paiement a changé d'aspect, ou les clients doivent saisir leur carte deux fois.
• Plusieurs clients signalent une fraude sur leur carte peu après un achat chez vous.
• Votre prestataire de paiement vous contacte au sujet de fraudes en série.
• Vous découvrez des fichiers ou des scripts inconnus sur le serveur, ou des fichiers du thème modifiés récemment sans raison.
• Un compte administrateur que vous ne connaissez pas apparaît dans le back-office.
• Un client vous signale une alerte de son antivirus ou de son navigateur en visitant votre boutique.

Astuce : testez de temps en temps votre tunnel de commande dans une fenêtre de navigation privée, sans être connecté au back-office.

Les protections concrètes

Tenir à jour PrestaShop, les modules et PHP

C'est la mesure la plus efficace : la plupart des attaques exploitent des failles déjà connues et corrigées. Appliquez les mises à jour de sécurité de PrestaShop et des modules, et faites évoluer la version de PHP. Si votre boutique tourne encore sous une ancienne version, lisez notre article PrestaShop 1.6 en 2026 : quels risques à rester sur une ancienne version ?.

Supprimer les modules inutilisés

Un module désactivé reste présent sur le serveur, et une faille peut parfois être exploitée même s'il est désactivé. Faites l'inventaire : ce qui ne sert plus doit être désinstallé puis supprimé.

Choisir un paiement hébergé chez votre prestataire

Avec un paiement « redirigé » ou « hébergé », le client saisit sa carte sur la page de votre banque ou de votre prestataire, pas sur votre boutique. Même si votre site est compromis, le vrai formulaire reste hors d'atteinte.

Attention toutefois : cela ne protège pas contre le faux formulaire ajouté avant la redirection. C'est exactement la technique observée sur PrestaShop en 2022 et en 2026. Le paiement hébergé est donc nécessaire, mais il ne dispense pas des autres mesures.

Protéger l'accès au back-office

Des mots de passe longs et uniques. Le moins de comptes administrateurs possible, en supprimant ceux des anciens prestataires ou salariés. Si possible, limitez l'accès au back-office à certaines adresses IP et activez une double authentification.

Sauvegarder base de données et fichiers, tous les jours

Une sauvegarde saine permet de revenir à un état propre après un incident. Elle doit couvrir la base de données et les fichiers, être réalisée chaque jour par des procédures automatiques, et être conservée sur plusieurs jours, hors du serveur. Gardez des sauvegardes anciennes : un skimmer peut rester discret pendant des semaines. Pour la méthode, voyez notre article Sauvegarder sa boutique PrestaShop avant une intervention.

Surveiller les fichiers modifiés

Les skimmers se logent souvent dans les fichiers du thème ou des modules. Un outil qui signale toute modification inattendue de fichier permet de réagir en quelques heures plutôt qu'en quelques mois.

Ajouter une politique de sécurité du contenu (CSP)

La Content-Security-Policy est une consigne envoyée par votre site au navigateur du client. Elle dit, en substance : « sur mes pages, n'exécute que les scripts venant de telle et telle adresse, et n'envoie des données qu'à celles-ci ». Si un pirate ajoute un script qui envoie les cartes vers son propre serveur, le navigateur peut le bloquer. Une règle trop stricte peut bloquer un module légitime (paiement, statistiques) : elle se teste donc d'abord en mode « observation ».

Que faire si vous soupçonnez une attaque

1. Ne supprimez pas tout dans la précipitation. Les fichiers suspects et les journaux du serveur sont des preuves : ils montrent par où le pirate est entré.
2. Mettez la boutique en maintenance, ou au minimum désactivez le paiement, le temps de l'analyse.
3. Prévenez votre prestataire de paiement. Il peut surveiller les transactions et vous guider.
4. Faites analyser la boutique par un professionnel : recherche du code malveillant, de son origine, et de tout ce qui a été modifié.
5. Changez tous les mots de passe : back-office, hébergement, accès FTP/SSH, base de données, messagerie.
6. Notifiez la CNIL si des données personnelles sont concernées, dans le délai de 72 heures évoqué plus haut. Si vous hésitez, la CNIL recommande de notifier : elle vous dira si vos clients doivent être informés.
7. Portez plainte auprès de la police ou de la gendarmerie. La plateforme Cybermalveillance.gouv.fr recommande de le faire avant de réinstaller quoi que ce soit, pour conserver les preuves.
8. Restaurez à partir d'une sauvegarde saine, puis appliquez toutes les mises à jour avant de rouvrir.

En résumé

Le vol de données bancaires repose presque toujours sur les mêmes ressorts : un logiciel pas à jour, un module vulnérable, un accès mal protégé. Mises à jour régulières, paiement hébergé, sauvegardes quotidiennes et surveillance des fichiers réduisent fortement le risque. En cas de doute, réagir avec méthode compte plus que réagir vite. Et mieux vaut être bien entouré.