Attaque “digital skimmer” sur PrestaShop : guide complet pour vérifier, nettoyer et sécuriser votre boutique
Les boutiques e-commerce sont une cible privilégiée des cybercriminels, notamment lorsqu’elles traitent des paiements en ligne. Ces derniers jours, une menace spécifique a été signalée dans l’écosystème PrestaShop : un script malveillant de type “digital skimmer”, capable de remplacer les boutons de paiement par de faux boutons et de rediriger les clients vers un formulaire frauduleux afin de voler leurs informations de paiement.
Si vous gérez une boutique PrestaShop (ou plusieurs), il est essentiel d’agir vite : un skimmer n’est pas un simple “bug”, c’est un incident de sécurité qui peut impacter vos clients, votre réputation et votre conformité (RGPD).
Dans ce guide, vous allez apprendre comment reconnaître les symptômes, où vérifier dans PrestaShop, quoi faire en cas d’infection, comment remettre votre boutique “au propre” durablement et comment prévenir la réapparition de ce type d’attaque.
1) Qu’est-ce qu’un “digital skimmer” et pourquoi c’est grave ?
Un digital skimmer (parfois classé dans les attaques “Magecart-like”) est un malware conçu pour intercepter des données sensibles lors d’un paiement : informations client, données de transaction, et parfois des informations de carte ou des données assimilées. L’objectif est simple : voler des informations de paiement tout en restant discret, afin que la boutique continue à encaisser des commandes “normalement”.
Dans les cas observés sur des boutiques PrestaShop, le scénario est souvent le même :
- L’attaquant parvient à modifier un fichier de la boutique (accès FTP compromis, back-office piraté, module vulnérable, mot de passe faible, etc.).
- Il injecte un script dans un fichier du thème, souvent dans la zone
<head>. - Le script altère le tunnel de commande et remplace les boutons de paiement légitimes par des boutons frauduleux.
- Le client clique, puis est redirigé vers un formulaire contrefait destiné à capturer ses informations.
Le problème est majeur : vous risquez non seulement de perdre la confiance des clients, mais aussi de subir des litiges, des demandes de remboursement, et des obligations de notification liées à la protection des données.
2) Les signes qui doivent vous alerter
Un skimmer peut rester invisible longtemps, mais certains signaux reviennent fréquemment :
- Des clients signalent une redirection étrange ou un paiement inhabituel.
- Le tunnel de commande affiche un bouton de paiement non attendu (texte, style, logo, ordre des moyens de paiement).
- Votre hébergeur, un WAF ou un outil de sécurité remonte une injection ou un fichier modifié.
- En affichant le code source, vous repérez un
<script>inconnu, obfusqué, ou chargé depuis un domaine que vous ne reconnaissez pas. - Des fichiers du thème ou du serveur ont été modifiés sans intervention de votre équipe.
Important : certains scripts se déclenchent uniquement sur des pages spécifiques, notamment la page de commande. Cela rend la détection plus difficile si vous ne testez pas le checkout régulièrement.
3) Où vérifier en priorité dans PrestaShop ?
Dans plusieurs incidents, le script est injecté dans un fichier du thème, notamment :
themes/votre-theme/templates/_partials/head.tpl
Pourquoi ce fichier ? Parce qu’il est chargé très tôt, sur de nombreuses pages, et qu’un script placé dans le <head> peut facilement influencer l’affichage et le comportement du tunnel de commande (boutons, redirections, formulaires, scripts tiers, etc.).
Vérification rapide côté navigateur
Sans être développeur, vous pouvez déjà faire un premier contrôle :
- Ouvrez la boutique en navigation privée.
- Allez jusqu’au tunnel de commande (panier > commande).
- Clic droit > “Afficher le code source” ou “Inspecter”.
- Recherchez des signatures suspectes :
atob(,XMLHttpRequest,Function(, ou des domaines inconnus.
Un code volontairement obfusqué (illisible, encodé, avec des morceaux qui semblent “aléatoires”) doit être considéré comme suspect, surtout s’il touche la page de paiement.
4) Que faire immédiatement si vous suspectez une infection ?
Étape 1 : protéger vos clients
Si vous avez un doute sérieux, la priorité est de stopper l’exposition :
- Mettre la boutique en maintenance, ou
- Désactiver temporairement les paiements en ligne si vous avez une alternative.
Étape 2 : sauvegarder avant de nettoyer
Avant de supprimer quoi que ce soit :
- Réalisez une sauvegarde complète (fichiers + base de données).
- Conservez-la hors serveur (cloud, stockage externe).
- Cette sauvegarde sert de preuve, permet l’analyse et facilite une restauration propre si nécessaire.
Étape 3 : identifier et supprimer l’injection visible
Si vous repérez clairement la balise <script> malveillante dans head.tpl :
- Supprimez uniquement le bloc malveillant (sans casser le template).
- Purger les caches (cache PrestaShop + cache serveur si applicable).
- Re-tester le tunnel de commande sur plusieurs navigateurs.
Attention : supprimer le script dans head.tpl ne règle pas forcément la cause. Si un attaquant a pu modifier un fichier, il faut considérer que le site a été compromis jusqu’à preuve du contraire.
5) Nettoyage complet : la méthode “propre” recommandée
Lorsqu’un site e-commerce est compromis, la bonne approche consiste à repartir sur une base saine, plutôt que de faire des corrections “au coup par coup”. Une remise en état sérieuse se déroule généralement ainsi :
A) Réinstaller un cœur PrestaShop sain
- Réinstaller des fichiers core PrestaShop provenant d’une source officielle et propre.
- Ne conserver que ce qui est nécessaire :
/img,/upload,/download(selon votre boutique), et les contenus clients indispensables.
B) Auditer le thème et les modules
- Thème : contrôler les fichiers sensibles (head, footer, templates checkout, JS, overrides).
- Modules : supprimer les modules inutiles et auditer ceux qui touchent au paiement, au tunnel de commande, ou à l’injection de scripts.
- Éviter strictement les modules “nulled” ou provenant de sources non fiables.
C) Changer tous les accès
Indispensable après incident :
- Mots de passe du back-office (et comptes employés).
- Accès FTP/SFTP/SSH et panel d’hébergement.
- Accès base de données (utilisateur + mot de passe).
- Clés API : modules de paiement, SMTP, services externes, webhooks.
D) Vérifier les comptes et droits
- Contrôler qu’aucun compte admin/employé inconnu n’a été créé.
- Réduire les droits au strict nécessaire (principe du moindre privilège).
- Analyser les logs si disponibles (connexions, actions, imports, modifications).
6) Prévenir la réinfection : bonnes pratiques durables
Une boutique PrestaShop doit être gérée comme un système critique : mises à jour, contrôle des accès, sauvegardes, et protection serveur.
Mettre à jour PrestaShop, le thème et les modules
Les attaques exploitent très souvent des vulnérabilités connues. Maintenir PrestaShop, le thème et les modules à jour est la mesure la plus rentable en sécurité.
Renforcer l’accès au back-office
- URL admin personnalisée.
- Mots de passe forts et uniques, gestionnaire de mots de passe recommandé.
- Double authentification si disponible (ou via solution serveur).
- Restriction d’accès par IP (quand c’est possible).
- Limiter le nombre de comptes administrateurs.
Protéger le serveur
- Permissions de fichiers strictes (éviter le 777, limiter l’écriture aux dossiers nécessaires).
- Durcissement PHP (désactiver des fonctions risquées si non nécessaires).
- WAF (pare-feu applicatif) : Cloudflare, ModSecurity ou équivalent.
- Surveillance de l’intégrité des fichiers (alertes en cas de modification).
Sauvegardes et plan de reprise
- Backups automatiques quotidiens (au minimum).
- Stockage hors serveur.
- Tests de restauration (souvent négligés, mais essentiels).
7) Et le RGPD dans tout ça ?
Si des données de paiement ont potentiellement été exposées, il peut exister des obligations liées à la protection des données (RGPD), notamment en matière de notification et d’information. Sans entrer dans le juridique détaillé, retenez ceci : si le risque est avéré, il faut traiter l’incident sérieusement, documenter les actions menées, et vous entourer si nécessaire (DPO, conseil, prestataire sécurité).
8) Checklist express : audit en 30 minutes
- Mettre en maintenance si le doute est sérieux.
- Sauvegarder fichiers + base de données.
- Vérifier
themes/.../_partials/head.tpl. - Rechercher des scripts obfusqués, domaines inconnus,
atob(. - Contrôler la page checkout : boutons, redirections, comportement.
- Identifier les fichiers récemment modifiés (via l’hébergeur ou SSH).
- Changer les mots de passe (BO, FTP, hébergeur) + clés API sensibles.
- Mettre à jour PrestaShop / modules / thème.
- Installer des protections (WAF, restrictions, monitoring).
Besoin d’aide ? Diagnostic et sécurisation PrestaShop
Si vous avez un doute sur votre boutique PrestaShop, un audit rapide permet de confirmer l’intégrité du tunnel de commande et d’éliminer les injections ou portes dérobées :
- Analyse du thème et des fichiers sensibles.
- Vérification du tunnel de commande et des scripts chargés.
- Recherche d’injections, de modifications suspectes et de backdoors.
- Mise en place d’un plan de sécurisation et de surveillance.
Conseil : en e-commerce, mieux vaut intervenir tôt. Une action rapide limite le risque client, réduit l’impact commercial et protège votre réputation.
FAQ : questions fréquentes
Un antivirus suffit-il pour détecter un skimmer ?
Non. Un skimmer peut être discret et se déclencher uniquement sur certaines pages. Il faut une vérification ciblée du tunnel de commande, des templates du thème et des scripts chargés.
Pourquoi le fichier head.tpl est-il souvent visé ?
Parce que le <head> est chargé très tôt et permet d’exécuter du JavaScript sur une grande partie du site. Un script placé ici peut modifier l’affichage et le comportement des paiements.
Si je supprime le script, est-ce que le problème est réglé ?
Pas toujours. La suppression corrige le symptôme visible, mais si l’attaquant a conservé un accès (mot de passe compromis, module vulnérable, backdoor), l’infection peut revenir. Il faut corriger la cause et sécuriser l’ensemble.
Comment éviter que cela se reproduise ?
La meilleure protection repose sur un ensemble de mesures : mises à jour régulières, accès back-office renforcé, suppression des modules inutiles, WAF, sauvegardes fiables et surveillance des fichiers modifiés.
Dois-je informer mes clients ?
Si vous suspectez une exposition de données de paiement, il est recommandé de documenter l’incident et de vous entourer pour décider des actions appropriées (communication, mesures de protection, conformité). Agir vite et avec transparence protège vos clients et votre image.
