Réagir à une fuite de données : que faire si votre boutique est piratée

Le pire moment pour improviser votre plan de réponse à incident, c’est à 2 heures du matin, devant un e-mail client qui dit : « votre paiement m’a débité deux fois et maintenant je reçois des SMS d’hameçonnage ». Si vous exploitez une boutique PrestaShop assez longtemps, il existe une vraie probabilité que vous soyez confronté à une compromission. Les petites et moyennes boutiques sont ciblées en permanence, non pas parce qu’elles sont spécialement visées, mais parce que des scanners automatisés diffusent des exploits PrestaShop et modules connus sur tout le Web et sonnent à chaque porte restée ouverte. Ce guide est le plan d’action pour après le déclenchement de l’alerte : une séquence calme et ordonnée de ce qu’il faut vérifier, préserver et inspecter dans les emplacements propres à PrestaShop que l’attaquant a presque certainement touchés. Ce n’est volontairement pas un guide de prévention, si vous êtes ici avant qu’un problème ne survienne, commencez plutôt par la check-list de durcissement de la sécurité PrestaShop.

Lisez-le une fois maintenant, tant que rien ne brûle. Le meilleur indicateur d’une reprise propre, c’est de connaître l’ordre des opérations avant d’en avoir besoin.

Relu en juin 2026 au regard des structures actuelles de fichiers et de base de données de PrestaShop 1.6, 1.7, 8 et 9, ainsi que de la règle RGPD de notification des violations sous 72 heures en vigueur au moment de la rédaction.

Avant de toucher à quoi que ce soit : préservez les preuves

Une loupe passe sur une grille d’icônes de fichiers et de dossiers lumineuses, quelques-unes mises en évidence en orange.

Si vous disposez d’un accès shell, copiez les fichiers, la base de données et les journaux avant de supprimer quoi que ce soit. Adaptez le nom de la base et les chemins à votre hébergement.

#!/usr/bin/env bash
set -euo pipefail

stamp=$(date +%F-%H%M%S)
case_dir="/root/prestashop-incident-$stamp"
mkdir -p "$case_dir"

tar --xattrs --acls -czf "$case_dir/files.tgz" /var/www/html
mysqldump --single-transaction --routines --triggers prestashop > "$case_dir/database.sql"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$case_dir/" 2>/dev/null || true

sha256sum "$case_dir"/* > "$case_dir/SHA256SUMS"
chmod -R go-rwx ";$case_dir

Le réflexe consiste souvent à se connecter au back-office et à commencer à supprimer les fichiers suspects. Résistez. Dès que vous modifiez quelque chose, vous détruisez la piste qui permet de comprendre comment ils sont entrés, et si vous ne trouvez pas le point d’entrée, vous serez de nouveau compromis en quelques jours. Votre première action doit être de copier, pas nettoyer.

Prenez un instantané complet avant toute remédiation :

• Toute la racine web, votre répertoire PrestaShop, y compris les fichiers cachés (.htaccess, .user.ini). Les attaquants les adorent, car peu de personnes les auditent.
• Une sauvegarde de la base de données, exécutez mysqldump sur toute la base. L’injection se trouve souvent dans la base, pas seulement sur le disque (voir plus bas).
• Les journaux, journaux d’accès et d’erreur du serveur web (/var/log/nginx/ ou /var/log/apache2/), journaux PHP-FPM et journaux propres à PrestaShop sous var/logs/ (PS 1.7+) ou log/ (PS 1.6). Les journaux tournent et disparaissent ; récupérez-les en premier.

Stockez cet instantané dans un endroit que l’attaquant ne peut pas atteindre, votre ordinateur portable ou un nouvel espace de stockage cloud, pas un second dossier sur le même serveur compromis. C’est ce que l’équipe abus de votre hébergeur, un expert en investigation numérique ou votre assurance cyber vous demandera, et c’est le seul moyen de reconstruire une chronologie plus tard.

Contenir l’hémorragie sans détruire la scène

Le confinement et l’analyse forensique tirent dans des directions opposées : vous voulez stopper les dégâts, mais débrancher brutalement peut effacer des preuves volatiles (sessions actives, processus de l’attaquant). Pour une boutique typique, le bon équilibre consiste à mettre la boutique hors ligne pour les clients, tout en laissant le serveur lui-même fonctionner afin de pouvoir enquêter.

PrestaShop intègre un mode maintenance. Dans le back-office, allez dans Paramètres de la boutique → Général → Maintenance (PS 1.7/8/9) et désactivez la boutique, puis ajoutez votre propre IP dans le champ IP de maintenance afin de continuer à travailler pendant que les clients voient une page d’attente. Les indicateurs sous-jacents sont PS_SHOP_ENABLE et PS_MAINTENANCE_IP dans la table ps_configuration. Utile si le back-office lui-même est verrouillé ou défiguré et que vous devez basculer l’état directement en base de données.

Si des données de paiement peuvent être concernées, le mode maintenance ne suffit pas, et ne commencez pas par fouiller les fichiers. Deux appels passent avant toute opération technique :

• Votre prestataire de paiement. Stripe, PayPal, Mollie, Adyen, votre banque acquéreuse, celui qui encaisse vos paiements. Ces acteurs disposent d’équipes fraude capables de surveiller les schémas de test de cartes et de signaler les cartes touchées. Si un skimmer de carte a été injecté dans votre tunnel de commande, c’est ainsi que les cartes exposées peuvent être surveillées avant d’être utilisées abusivement.
• Votre hébergeur. De nombreuses compromissions commencent au niveau du compte d’hébergement, pas de l’installation PrestaShop, et votre hébergeur voit des choses que vous ne voyez pas (autres sites sur le même compte, spam sortant, tâche cron qui mine de la cryptomonnaie).

Où les attaquants PrestaShop se cachent réellement

C’est la partie que les articles génériques « vous avez été piraté » passent sous silence, et c’est pourtant l’essentiel. Connaître les emplacements précis où vivent les infections PrestaShop transforme un « tout scanner » désespéré en recherche ciblée. En ordre approximatif de fréquence constatée :

Premier balayage pratique côté serveur : listez tous les fichiers PHP modifiés au cours des 30 derniers jours et lisez chaque fichier inconnu. Depuis votre racine web, find . -name "*.php" -mtime -30 -ls fait remonter les fichiers récemment touchés ; comparez-les avec une copie propre de la même version de PrestaShop (téléchargez la version exacte depuis le site officiel) afin de distinguer les fichiers du cœur des fichiers altérés. Portez une attention particulière à tout PHP présent sous img/ ou upload/, ces répertoires ne devraient jamais contenir de PHP exécutable, et une seule ligne dans votre .htaccess refusant l’exécution de PHP à cet endroit est l’un des durcissements les moins coûteux une fois le site propre.

Déposez un tout petit .htaccess dans chaque répertoire d’envoi (img/, upload/, download/) afin que, même si un shell y atterrit de nouveau, le serveur refuse de l’exécuter. Sur Apache 2.4 :

# img/.htaccess (and upload/, download/) – refuse to execute PHP
<FilesMatch "\.(php|php\d|phtml|phar)$">
    Require all denied
</FilesMatch>
php_flag engine off

C’est du confinement, pas une correction : cela empêche un web shell déposé de s’exécuter, mais ne dit rien sur la façon dont le fichier a pu être écrit au départ, c’est l’objet de la recherche du point d’entrée plus bas.

Côté base de données, exportez la table et comparez votre liste ps_employee aux personnes que vous employez réellement ; recherchez aussi dans les contenus CMS et de configuration <script, base64_decode, eval( et les domaines externes que vous ne reconnaissez pas. Si la violation s’avère être précisément un skimmer de paiement, il vaut la peine de comprendre en détail la mécanique de son intrusion et de l’exfiltration des cartes, nous avons disséqué un cas réel dans l’anatomie d’une attaque de type Magecart sur une boutique PrestaShop.

Verrouiller les portes : changer tous les identifiants que l’attaquant peut détenir

Partez du principe que l’attaquant possède une copie de tout ce qu’il a pu lire, et remplacez tout. Sur PrestaShop, ce « tout » est plus long qu’on ne l’imagine, et oublier un seul élément lui permet de revenir directement :

• Tous les mots de passe des employés du back-office, et supprimez tout compte que vous ne pouvez pas expliquer. Forcez une réinitialisation pour toute l’équipe, pas seulement pour vous.
• Les identifiants de base de données dans config/settings.inc.php (PS 1.6) ou app/config/parameters.php (PS 1.7+). Changez le mot de passe de l’utilisateur MySQL et mettez le fichier à jour dans la même opération.
• Les clés de cookie, les constantes _COOKIE_KEY_/_COOKIE_IV_ dans settings.inc.php sur PS 1.6, ou les valeurs cookie_key/cookie_iv (et new_cookie_key lorsqu’elle existe sur PS 8/9) dans parameters.php sur PS 1.7+. Si elles ont fuité, d’anciens cookies de session admin peuvent encore être valides. Changer les clés seules ne suffit pas : après la rotation, videz les sessions actives côté serveur et le cache, puis forcez chaque employé à se déconnecter et à réinitialiser son mot de passe, c’est ce qui tue réellement la session de l’attaquant.
• Les accès FTP/SFTP, SSH et au panneau d’hébergement. Un mot de passe FTP volé est la manière la plus courante pour un site « nettoyé » d’être réinfecté en quelques heures.
• Toutes les clés API / secrets de webhooks pour les intégrations de paiement et de transport stockées dans la configuration des modules.

Une fois les identifiants changés, c’est le moment de fermer durablement la porte avec l’authentification à deux facteurs sur le back-office, afin qu’un mot de passe divulgué ne suffise plus à lui seul, la procédure se trouve dans l’authentification à deux facteurs, les politiques de mot de passe et la sécurité admin pour PrestaShop. Si votre enquête montre que l’attaque est entrée par martèlement de la connexion ou via des IP abusives, ajouter des bannissements d’IP et un reCAPTCHA sur le formulaire de connexion limite les tentatives de connexion automatisées. Ne le considérez toutefois pas comme une correction complète. ReCAPTCHA peut être contourné et ne fait rien contre le bourrage d’identifiants avec un mot de passe volé valide ; combinez-le donc avec la 2FA, la limitation de débit et le bridage par IP, des mots de passe employés forts et uniques, ainsi qu’une surveillance des journaux.

Le compte à rebours de 72 heures : vos obligations RGPD

Si votre boutique a des clients européens, et si vous livrez dans l’UE ou utilisez un prestataire de paiement européen, c’est le cas, le RGPD transforme un incident technique en sujet juridique avec une échéance ferme. La règle qui surprend souvent : vous disposez de 72 heures à compter du moment où vous avez connaissance de la violation pour notifier votre autorité de contrôle (l’autorité de protection des données de votre pays), sauf si la violation est peu susceptible d’engendrer un risque pour les droits des personnes. Une violation impliquant des mots de passe clients, des adresses ou des données de paiement franchit facilement ce seuil ; prévoyez donc de notifier.

Si la violation est susceptible de présenter un risque élevé pour les personnes concernées, là encore, les données de paiement et les mots de passe en font partie, vous devez aussi notifier les clients touchés directement, en langage clair, en leur indiquant ce qui s’est passé, quelles données sont concernées, ce que vous faites et ce qu’ils doivent faire (changer leur mot de passe, surveiller leurs relevés, s’attendre à de l’hameçonnage faisant référence à la violation). C’est exactement pour cela que l’instantané des preuves de la première étape compte : vous ne pouvez pas rédiger une notification honnête si vous avez détruit les données qui disent ce qui a réellement été consulté. Le compte à rebours de 72 heures démarre quand vous devenez conscient de la violation, pas quand vous avez terminé l’enquête, la première notification part donc souvent pendant que la remédiation est encore en cours, avec un complément lorsque vous en savez davantage. C’est autorisé et attendu.

Un point pratique facile à oublier : ce délai court en parallèle de tout le reste dans ce guide. Confinement, analyse forensique et notification légale ont lieu en même temps, ce qui explique pourquoi il faut tenir un journal horodaté de toutes vos actions dès la première heure. Ce journal est à la fois votre chronologie d’investigation et la preuve de votre diligence si un régulateur la demande.

Prévenir les clients sans aggraver la situation

Les clients pardonnent à la boutique qui les a prévenus en premier et méprisent celle dont ils ont appris l’incident par leur banque ou par la presse. Le rôle de la notification est d’être honnête et utile, pas de minimiser. Expliquez ce qui s’est passé en termes humains, dites exactement lesquelles de leurs données sont concernées et quelles actions précises ils doivent entreprendre, puis dirigez les réponses vers un canal qui ne noiera pas votre service client habituel. Une adresse dédiée à la réponse à incident évite que les e-mails paniqués du type « suis-je concerné ? » se mélangent aux questions de commande.

Préparez-vous aussi aux opportunistes : les notifications de violation sont une aubaine pour les hameçonneurs qui se feront passer pour vous afin « d’aider les clients à réinitialiser leur mot de passe ». Dites précisément aux clients, dans la notification, quel canal vous utiliserez et que vous ne leur demanderez jamais leur mot de passe, cela tient en une phrase et évite une deuxième vague de victimes.

Ne restaurez pas l’infection : reconstruire depuis un état propre

L’erreur de reprise la plus fréquente consiste à restaurer la sauvegarde de la nuit précédente. Si l’attaquant était présent depuis deux semaines, la sauvegarde d’hier soir contient aussi la porte dérobée, vous restaurerez la compromission et la redécouvrirez le mois prochain. Remontez depuis votre instantané de preuves pour identifier quand le premier fichier malveillant ou la première ligne employé est apparu, puis restaurez soit une sauvegarde antérieure, soit, plus fiable encore, reconstruisez proprement :

• Réinstallez le cœur de PrestaShop depuis un téléchargement frais de votre version exacte, remplacez les fichiers du cœur en bloc plutôt que d’essayer de les nettoyer chirurgicalement.
• Réinstallez chaque module depuis sa source d’origine (le développeur, pas votre copie potentiellement altérée). Tout ce que vous ne pouvez pas obtenir proprement doit être écarté.
• Réappliquez uniquement les fichiers override/ et les modifications de thème que vous pouvez expliquer avec certitude.
• Migrez les données (commandes, clients, produits) depuis la base, mais seulement après y avoir recherché et éliminé les charges utiles injectées.

C’est aussi le moment de corriger votre stratégie de sauvegarde afin qu’une reconstruction propre soit réellement possible la prochaine fois : sauvegardes quotidiennes automatisées, stockées hors du serveur de production, avec une rétention suffisante (pensez à 30 jours ou plus) pour remonter au-delà d’une compromission lente. Une sauvegarde qui ne remonte qu’à trois jours ne sert à rien contre un attaquant resté discret pendant quinze jours.

Une fois la poussière retombée : fermer définitivement le vecteur

Vous avez trouvé le point d’entrée pendant l’analyse forensique, fermez-le maintenant pour de bon, car une nouvelle compromission par la même faille est la suite la plus courante d’une violation. La correction dépend de ce que l’enquête a révélé :

• PrestaShop obsolète ou module vulnérable ? Mettez à jour. Si vous ne pouvez réellement pas encore mettre à niveau le cœur (réalité fréquente sur des boutiques 1.6/1.7 très personnalisées), le patching virtuel permet de bloquer l’exploit connu au niveau de la requête sans toucher au code, c’est couvert dans le durcissement avancé pour les boutiques que vous ne pouvez pas encore mettre à niveau.
• Mot de passe admin faible ou réutilisé ? Politique de mot de passe plus 2FA, comme dans le guide de sécurité admin.
• Sécurité du transport manquante ou .htaccess trop permissif ? Configurez correctement HTTPS (configuration SSL/HTTPS) et verrouillez les règles serveur (règles de sécurité .htaccess), y compris le refus d’exécuter PHP dans les répertoires d’envoi.
• Vous ne savez même pas par où commencer le durcissement ? Le guide en langage clair pour les non-développeurs est sécuriser votre boutique PrestaShop, et la version exhaustive est la check-list de durcissement de la sécurité.

Questions fréquentes

Comment savoir si ma boutique PrestaShop a vraiment été piratée, ou s’il s’agit seulement de spam ?

Cherchez les éléments qu’un spammeur ne peut pas simuler : une ligne ps_employee que vous n’avez pas créée, des fichiers PHP modifiés ces derniers jours sans intervention de votre part (find . -name "*.php" -mtime -7), du PHP exécutable sous img/ ou upload/, des <script ou base64_decode inattendus dans vos pages CMS ou votre configuration, ou votre boutique qui redirige les visiteurs ailleurs mais pas vous. Les paniers indésirables et le spam de formulaires sont bruyants mais inoffensifs ; de nouveaux comptes admin, des scripts injectés et des fichiers du cœur altérés indiquent une compromission.

Dois-je mettre ma boutique hors ligne immédiatement ?

Mettez la boutique hors ligne pour les clients avec le mode maintenance, mais laissez le serveur fonctionner pour pouvoir enquêter. Éteindre toute la machine efface des preuves volatiles (sessions actives, processus de l’attaquant) avant que vous ayez compris comment ils sont entrés, et sans le point d’entrée, vous serez réinfecté en quelques jours. La seule exception est un skimmer de carte actif dans le tunnel de commande : dans ce cas, stopper l’hémorragie côté clients passe en premier, et vous appelez votre prestataire de paiement en parallèle.

Ne puis-je pas simplement restaurer la sauvegarde de la nuit dernière et passer à autre chose ?

Généralement non. Si l’attaquant était présent depuis deux semaines, la sauvegarde de la nuit dernière contient aussi la porte dérobée ; vous restaureriez donc la compromission et la redécouvririez le mois prochain. Remontez depuis votre instantané de preuves pour trouver quand le premier fichier malveillant ou la première ligne employé est apparu, puis restaurez une sauvegarde antérieure, ou, plus fiable encore, reconstruisez proprement depuis un téléchargement frais du cœur et les sources originales des modules, en ne migrant que les données que vous avez contrôlées et nettoyées.

Dois-je signaler la violation à quelqu’un ?

Si votre boutique a des clients dans l’UE et que la violation a touché des données personnelles (mots de passe, adresses, données de paiement), le RGPD vous donne 72 heures à compter du moment où vous en avez connaissance pour notifier votre autorité de contrôle, et vous devez notifier directement les clients concernés si le risque pour eux est élevé. Le délai commence quand vous en prenez connaissance, pas quand vous terminez l’enquête ; la première notification part donc souvent pendant que la remédiation est encore en cours, avec un complément plus tard. C’est normal.

Comment éviter que cela se reproduise ?

Fermez le vecteur précis que votre analyse forensique a mis au jour, corrigez le cœur ou le module obsolète, éliminez le mot de passe admin faible, sécurisez le répertoire d’envoi trop permissif, car une nouvelle compromission par la même faille est la suite la plus courante d’une violation. Ajoutez ensuite les couches qui rendront la prochaine tentative plus difficile : 2FA sur le back-office, sauvegardes hors serveur avec au moins 30 jours de rétention, et la check-list de durcissement complète.

La partie vraiment difficile de la reprise après violation n’est pas le nettoyage, c’est de savoir à quel moment vous avez réellement refermé toutes les portes, car une porte dérobée oubliée vous oblige à tout recommencer. Si vous préférez ne pas porter cette incertitude seul, notre équipe conçoit et audite des boutiques PrestaShop au quotidien et intervient directement avec les marchands sur exactement ce type d’incident, sans intermédiaire, sans couche de revente. Concrètement, qu’est-ce que cela vous apporte ? Un deuxième regard qui sait où se cachent les infections PrestaShop, afin que vous puissiez rouvrir la boutique avec la certitude qu’elle est vraiment propre, plutôt qu’en l’espérant.

Dernière chose, et c’est la plus importante : notez ce que vous avez fait, dans l’ordre, avec les horodatages, dès que l’urgence immédiate est passée. Ce dossier est votre preuve RGPD, votre dossier d’assurance et, lorsque vous le relirez calmement la semaine suivante, l’audit de sécurité le plus honnête que vous aurez jamais de votre propre boutique. La plupart des violations remontent à une mise à jour repoussée ou à un mot de passe partagé par tous. Ce n’est pas de la malchance ; c’est la liste de tâches que vous n’avez désormais plus aucune excuse d’ignorer.