Le formulaire de paiement s’affiche deux fois pendant la commande

Pourquoi la double saisie est le symptôme le plus fiable

Un client vous écrit qu’il a dû saisir deux fois sa carte : la première page a semblé se recharger, puis le formulaire de paiement habituel lui a redemandé les mêmes informations. La commande est bien passée, le montant est correct, un seul débit apparaît. Côté back-office, rien ne cloche.

C’est précisément la signature d’une technique que Sansec a documentée en février 2026 sous le nom de « double-tap skimming », détectée le 16 février 2026 sur la boutique d’une chaîne de supermarchés figurant dans le top 10 mondial — environ 100 milliards d’euros de chiffre d’affaires annuel, plus de 10 000 magasins dans 25 pays — dont une partie de l’infrastructure e-commerce tourne sous PrestaShop. Un faux formulaire de paiement s’affiche d’abord et capture les données de carte, puis le vrai formulaire prend le relais et la commande se termine normalement. La plupart des clients acceptent cette double saisie sans se douter que les données ont déjà été volées.

Le symptôme est fiable parce qu’il est structurel. Le vol a besoin que le client remplisse un formulaire qui n’aboutit à rien, donc il a besoin de lui faire recommencer. Côté marchand, aucune alerte, aucun taux d’échec anormal, aucune ligne étrange dans les commandes : l’information ne remonte que par un client qui trouve ça bizarre, ou par un remboursement pour fraude un mois plus tard.

Où regarder : les fichiers du thème, puis la base de données

Sansec cite deux endroits côté marchand. D’abord des balises de script injectées dans les fichiers du thème, en particulier _partials/head.tpl sur PrestaShop : c’est le gabarit chargé sur toutes les pages, y compris celles du tunnel de commande. Ensuite, du JavaScript qui surveille les champs de saisie et stocke les valeurs dans le localStorage du navigateur avec un préfixe, pour les reprendre et les envoyer ailleurs. Je ne publie pas l’adresse de destination.

La base de données est l’autre endroit à ouvrir. PrestaShop a documenté en janvier 2025 une vague d’attaques exploitant des injections SQL dans des modules tiers, pas dans le cœur, pour insérer du contenu malveillant dans la valeur de configuration PS_SHOP_NAME. Cette valeur est ensuite utilisée pour charger du JavaScript non autorisé qui capture les saisies des clients. La vérification recommandée est directe : lire PS_SHOP_NAME en base et vérifier qu’elle ne contient rien d’autre que le nom de votre boutique. PrestaShop recommande par ailleurs de mettre à jour tous les modules natifs et tiers, d’utiliser un préfixe de base de données personnalisé plutôt que ps_, et de déployer un pare-feu applicatif.

Les deux chemins racontent la même histoire : un gabarit de thème et une valeur de configuration sont deux endroits que personne ne relit jamais, et qui décident pourtant de ce qui s’exécute sur la page de paiement.

Le paiement hébergé chez le prestataire ne met pas à l’abri

Beaucoup de marchands considèrent le sujet réglé parce que la saisie de carte se fait dans un cadre ou sur une page hébergée par le prestataire de paiement, et que les numéros ne transitent jamais par leur serveur. C’est exact pour le formulaire lui-même. Ça ne l’est pas pour la page qui l’entoure.

Dans le scénario de la double saisie, le code injecté n’attaque pas le champ du prestataire : il affiche sa propre surcouche avant, dans la page que vous contrôlez. Le client voit un écran de paiement crédible, dans sa langue et à votre marque — Sansec note que ces surcouches sont désormais soigneusement localisées et que les outils d’IA générative en accélèrent la production. Tant que la page qui héberge le paiement peut être modifiée, l’intégration hébergée ne protège pas du vol.

Ce que cette page ne contient pas

Je n’écris ici aucune méthode permettant de reproduire l’attaque, aucun code injecté, aucune adresse de destination et aucun moyen de repérer des boutiques vulnérables. Cette page sert à constater, vérifier et corriger, pas à outiller qui que ce soit.

Si l’un des signes décrits est présent, la suite n’est pas la correction d’un fichier isolé : c’est un nettoyage complet, le renouvellement de tous les accès, et la mise en place d’un contrôle d’intégrité sur la page de paiement pour que la prochaine modification soit détectée le jour même, pas un mois plus tard par une contestation bancaire.