Piratage de boutique en ligne : faux formulaire de carte, faux IBAN

J’ai un jour travaillé sur une boutique en ligne dont le moyen de paiement avait été remplacé au moment de la commande. Le client voyait la page habituelle et pensait payer la boutique. En réalité, sa carte bancaire ou son argent partait ailleurs. J’ai supprimé la modification sans l’analyser jusqu’au bout : je ne reconstitue donc pas le mécanisme de ce cas précis et je ne l’invente pas.

Le schéma général de ce type de piratage de boutique en ligne est pourtant bien connu grâce aux rapports des chercheurs en sécurité, et avant le Black Friday (27 novembre), tout propriétaire de boutique sous WooCommerce, PrestaShop ou Shopify a intérêt à le connaître.

Piratage de boutique en ligne : deux façons de détourner le paiement

Faux formulaire de carte bancaire

Un script étranger (un petit programme JavaScript qui s’exécute dans le navigateur du client) apparaît sur la page de paiement. Il copie le numéro de carte, la date d’expiration et le cryptogramme (les trois chiffres au dos) et les envoie au pirate. Ce script s’appelle un skimmer (comme le faux boîtier posé sur un distributeur de billets), on parle de skimming ou d’attaque Magecart. Le plus souvent, l’argent de la commande vous parvient bien, et la carte est utilisée ailleurs plus tard.

Coordonnées bancaires détournées

Ce qui change, c’est la destination de l’argent : l’IBAN pour le paiement par virement, l’adresse PayPal, le lien ou le bouton de paiement. Le client paie la totalité, de bonne foi, mais pas à vous. Vous voyez une commande en attente de paiement, alors que le client est sûr d’avoir payé.

L’ampleur du premier cas est mesurée. Selon le rapport de Recorded Future (février 2026), plus de 10 500 infections par ces skimmers étaient actives en 2025, dont plus de 7 300 nouvelles, et au moins 23 millions d’achats auraient été compromis par leur intermédiaire, d’après l’estimation de l’entreprise. Pour le second cas, il n’existe pas de statistiques globales.

Les cas de 2026 montrent comment le code étranger arrive sur le site :

• une extension vulnérable. En mai, Sansec a décrit une faille dans l’extension Funnel Builder pour WooCommerce (installée sur plus de 40 000 boutiques) : sans aucun mot de passe, le pirate inscrivait dans le réglage des scripts externes un faux « Google Tag Manager », qui chargeait ensuite le skimmer sur chaque page de paiement ;
• un fichier du thème. En février, PrestaShop a envoyé aux boutiques une alerte sur un script malveillant et leur conseillait de vérifier les fichiers de leur thème ;
• un script tiers. En octobre, un fichier d’analyse d’audience partagé par une plateforme brésilienne de boutiques en ligne a été piraté, et le skimmer s’est retrouvé sur les pages de paiement de ses boutiques ;
• un mot de passe volé pour l’administration, l’hébergement ou le FTP : dans ce cas, tout peut être modifié, y compris les coordonnées bancaires.

Pourquoi le propriétaire ne voit rien

Vous ouvrez votre boutique, tout est en place. Le skimmer est conçu exactement pour cela :

• il ne s’active que sur la page de paiement. Le skimmer que Sucuri a trouvé dans la base de données d’un WordPress en janvier 2025 vérifiait l’adresse de la page et ne se déclenchait que lors de la validation de commande ;
• il se cache de l’administrateur. Le script d’une campagne décrite par Silent Push (janvier 2026, active depuis au moins 2022) s’effaçait s’il détectait la barre d’administration de WordPress, c’est-à-dire vous ;
• la fausse « erreur de paiement ». Le client saisit sa carte dans le faux formulaire, le script récupère les données et affiche une erreur. Le client croit s’être trompé, saisit sa carte une seconde fois, cette fois dans le vrai formulaire, et le paiement passe. Vous avez une commande normale, le client découvre des débits inconnus deux semaines plus tard. Sansec appelle cela le « double-tap » et a trouvé ce schéma en février 2026 chez une grande enseigne sous PrestaShop ;
• il se camoufle. Les données partent vers des adresses qui ressemblent à des outils de mesure d’audience, et le code peut se trouver dans la base de données, là où un scanner de fichiers ne le voit pas.

Les signes à prendre au sérieux

• des clients signalent des débits inconnus sur leur carte après un achat chez vous. Un signalement isolé peut être une coïncidence, deux ou trois en peu de temps justifient une vérification ;
• des clients se plaignent d’une « erreur de paiement », puis tout est passé au second essai ;
• des commandes restent en attente de paiement alors que les clients vous envoient la preuve de leur virement ;
• un autre IBAN ou une autre adresse PayPal apparaît dans les réglages de paiement ou dans les e-mails de confirmation ;
• de nouveaux administrateurs que vous n’avez pas créés apparaissent dans l’administration ;
• des scripts que vous ne connaissez pas sont apparus dans les réglages de code additionnel ou de scripts externes, dans les widgets ou dans le thème ;
• un e-mail de votre banque, d’un service de paiement ou d’un chercheur en sécurité au sujet de votre site : ne le supprimez pas comme un spam.

Réduire le risque à l’avance

Le moyen de paiement. Le plus sûr est que la carte ne soit pas saisie sur votre site : le client clique sur « Payer » et arrive sur la page de la banque, de Stripe Checkout ou de PayPal. Le formulaire de carte n’est alors plus chez vous, et les scripts de votre site ne peuvent pas l’atteindre. La redirection ne supprime pas tout risque : on peut aussi remplacer le bouton ou le lien de paiement lui-même, mais les endroits où le paiement peut être détourné deviennent beaucoup moins nombreux.

Si le formulaire de carte est intégré à votre page (c’est souvent le cas des modules Stripe et d’autres prestataires), tout ce qui se charge sur cette page peut l’atteindre. Pour ces boutiques, la norme de sécurité des cartes PCI DSS 4.0.1 (que doit respecter quiconque accepte les cartes) exige depuis le printemps 2025 de tenir un inventaire des scripts de la page de paiement et de surveiller leurs modifications. Pour les sites qui envoient le client sur la page du prestataire, le PCI Security Standards Council (l’organisme qui gère la norme) a précisé en février 2025 que ce contrôle n’est pas exigé sur leur propre site.

Les mises à jour. CMS, thème, extensions et modules de paiement. Mais une mise à jour ferme la faille, elle ne nettoie pas ce que le pirate a déjà écrit en passant par cette faille : après la mise à jour de Funnel Builder, Sansec conseillait d’ouvrir le réglage des scripts externes et de supprimer tout ce qui est inconnu.

Les accès. Des mots de passe uniques pour l’administration, l’hébergement et la messagerie, la double authentification (un code sur le téléphone en plus du mot de passe), et une fois par mois, un coup d’œil à la liste des administrateurs pour supprimer ceux qui sont en trop.

Moins de code tiers sur la page de commande. Chaque outil de mesure d’audience, chat et pixel publicitaire sur la page de paiement est un script de plus auquel vous confiez les cartes de vos clients. Dans son guide de sécurité, Stripe conseille d’éviter le JavaScript provenant d’autres sites sur les pages de paiement.

La surveillance des modifications. Des extensions et des services de surveillance savent vous prévenir quand les fichiers du site ou la liste des scripts de la page de paiement changent. Pour les clients en maintenance, je contrôle une fois par jour les pages retenues du site avec mon propre outil de surveillance, à deux niveaux : le code source de la page et ce que le visiteur voit dans son navigateur. Pour une boutique, mieux vaut y inclure les pages de commande et de paiement : si un seul mot y change ou si un nouveau script y apparaît, je l’apprends au plus tard dans les 24 heures.

Une commande test, comme un client. Une fois par semaine, surtout en novembre, passez une commande depuis votre téléphone, sans être connecté à l’administration, dans une fenêtre de navigation privée. Ne payez pas avec votre carte principale, mais avec une carte virtuelle de l’application de votre banque (e-Carte Bleue ou équivalent) avec un petit plafond, ou allez jusqu’au formulaire de paiement et examinez-le attentivement sans saisir de carte. Annulez ensuite la commande et remboursez-vous. Vérifiez : le formulaire est-il le même que d’habitude ? Y a-t-il une « erreur » qui demande de saisir la carte à nouveau ? Les coordonnées bancaires de l’e-mail de confirmation sont-elles les bonnes ? Le skimmer peut ne pas se montrer à l’administrateur, mais il se montrera à un visiteur ordinaire. Pour préparer votre boutique aux grosses ventes, voir l’article « Préparer sa boutique en ligne pour le Black Friday et Noël ».

Si vous soupçonnez un détournement du paiement : que faire

1. Arrêtez l’encaissement. Désactivez le moyen de paiement ou passez la boutique en mode maintenance (avec une extension de mode maintenance, ou en demandant à l’hébergeur de fermer le site). Chaque heure d’ouverture expose de nouvelles cartes bancaires.
2. Gardez une copie comme preuve avant le nettoyage : fichiers, base de données, journaux du serveur (logs), captures d’écran de la page de paiement. C’est ce que recommande cybermalveillance.gouv.fr.
3. Trouvez et supprimez ce qui est étranger. Réglages des scripts externes et du code additionnel, widgets, thème, modules de paiement, coordonnées bancaires dans les réglages et dans les modèles d’e-mails. Dans WordPress, commencez par les widgets (Apparence > Widgets, si votre thème les propose) : les blocs « HTML personnalisé », c’est précisément là que Sucuri a trouvé le skimmer. Passez ensuite aux réglages du thème et des extensions qui insèrent du code dans l’en-tête et le pied de page. Le skimmer peut se trouver dans la base de données et non dans les fichiers. Pour les premiers signes de piratage de WordPress, voir l’article « Site WordPress piraté : les premiers signes ».
4. Fermez la porte d’entrée. Mettez tout à jour, changez les mots de passe de l’administration, de l’hébergement, du FTP et de la messagerie, supprimez les administrateurs inconnus, activez la double authentification. Sinon, le code reviendra.
5. Prévenez votre service de paiement et la banque qui encaisse les cartes pour vous : ils ont leurs propres procédures en cas de fuite de données de cartes.
6. La CNIL. Les numéros de carte et les noms des clients sont des données personnelles, et leur fuite est une violation de données. Selon l’article 33 du RGPD, elle doit être notifiée à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle est peu susceptible d’engendrer un risque pour les droits et libertés des personnes concernées, et les clients doivent être informés si le risque pour eux est élevé (article 34). En cas de doute, la CNIL conseille de notifier : elle vous indiquera s’il faut prévenir les personnes. Je ne suis pas juriste, référez-vous à la page de la CNIL.
7. Prévenez les clients de la période suspecte : qu’ils vérifient leurs relevés et, en cas de doute, appellent leur banque pour faire opposition sur leur carte.
8. Portez plainte auprès de la police ou de la gendarmerie, en ligne ou sur place, en joignant les copies conservées.

Si vous ne savez pas par où commencer, il existe un service public d’assistance en ligne, 17Cyber, et cybermalveillance.gouv.fr propose une liste de prestataires spécialisés.

Check-list avant les soldes et le Black Friday

• le paiement par carte se fait sur la page de la banque ou du service de paiement, ou bien vous savez quels scripts tournent sur votre page de paiement ;
• CMS, thème, extensions et modules de paiement sont à jour ;
• rien d’inconnu dans les réglages des scripts externes et du code additionnel ;
• l’IBAN et l’adresse PayPal dans les réglages et les e-mails sont bien les vôtres ;
• dans l’administration, seulement vos administrateurs, tous avec la double authentification ;
• les outils de mesure d’audience et les chats inutiles sont retirés de la page de paiement ;
• la commande test depuis le téléphone, sans connexion à l’administration, s’est passée sans « erreur », avec les bonnes coordonnées bancaires ;
• vous avez une copie récente du site et vous savez qui appeler en cas de problème.

Jusqu’où aller seul

Vérifier les coordonnées bancaires, les administrateurs et passer une commande test, tout propriétaire de boutique peut le faire en une demi-heure. En revanche, chercher sans expérience un skimmer qui se cache de l’administrateur et se loge dans la base de données est long et risqué : on peut supprimer la partie visible et laisser celle qui remettra tout en place.

Si votre temps vaut plus cher

Je peux prendre en charge la recherche et la suppression du code étranger, la vérification des coordonnées bancaires et la fermeture de la porte par laquelle il est entré : le nettoyage de site piraté est proposé à partir de 100 € HT. Et si vous voulez que quelqu’un vérifie régulièrement le paiement, les commandes et les mises à jour de votre boutique, il existe la formule Zen E-commerce à partir de 199 € HT par mois, conditions sur la page des tarifs.

Sources (vérifiées le 31 octobre 2026) : Annual Payment Fraud Intelligence Report: 2025, Recorded Future, février 2026 (en anglais) ; Funnel Builder vulnerability exploited, Sansec, 14 mai 2026 (en anglais) ; Global retailer PrestaShop store hacked, Sansec, 20 février 2026 (en anglais) ; Silent Push Uncovers New Magecart Network, Silent Push, 13 janvier 2026 (en anglais) ; PrestaShop security alert, 202-ecommerce, février 2026 (e-mail de PrestaShop du 12 février 2026, en anglais) ; Hackers hijack Convertr analytics script to steal payment card data, BleepingComputer, 27 octobre 2026, d’après Sansec (en anglais) ; Stealthy credit card skimmer targets WordPress checkout pages, Sucuri, janvier 2025 (en anglais) ; FAQ clarifies new SAQ A eligibility criteria, PCI Security Standards Council, 28 février 2025 (en anglais) ; Guide sur la sécurité en matière d’intégration, Stripe ; Fiche réflexe Défiguration de site Internet, cybermalveillance.gouv.fr ; Notifier une violation de données personnelles, CNIL ; libellés de l’administration WordPress d’après translate.wordpress.org.