Signes que votre boutique PrestaShop a besoin d’un audit de sécurité (et comment faire une première vérification vous-même)
Dernière mise à jour : juin 2026.
La plupart des boutiques PrestaShop n’ont pas besoin d’acheter un produit de sécurité. Elles ont besoin de connaître leur exposition réelle — et, très souvent, les propriétaires ne la connaissent tout simplement pas, parce que rien ne paraît anormal. Un skimmer peut rester des semaines sur une page de paiement pendant que les commandes continuent normalement. Un module vulnérable peut rester sans correctif pendant des années avant qu’un attaquant ne le repère par scan. L’objectif d’une revue de sécurité n’est pas de faire peur ; c’est de remplacer « je pense que tout va probablement bien » par une réponse claire, étayée par des éléments concrets. Cet article détaille les signes qui justifient un examen plus approfondi et vous donne un autocontrôle à effectuer en une dizaine de minutes avant de décider si vous avez besoin d’une aide extérieure.
Les signes qui comptent vraiment
Ils ne sont pas théoriques. Chacun d’eux correspond à une situation que nous avons déjà vue se transformer en incident réel sur de vraies boutiques. Lisez-les comme des facteurs de risque : plus ils s’appliquent à votre cas, plus un audit structuré mérite votre temps.
Vous utilisez une version ancienne ou en fin de vie de PrestaShop
PrestaShop 1.6 est en fin de vie depuis longtemps, et la majeure partie de la branche 1.7.x ne reçoit plus de correctifs de sécurité. Même en 8.x, une installation qui a quelques versions mineures de retard peut ne pas contenir les correctifs de failles connues publiquement. Un cœur ancien est le meilleur indicateur d’exposition, car les attaquants n’ont pas besoin de découvrir une nouvelle faille : ils scannent simplement les vulnérabilités déjà documentées. Si vous ne pouvez pas dire quelle version exacte vous utilisez sans vérifier, c’est déjà un signal.
Vos modules n’ont pas été mis à jour depuis des années
C’est la vraie surface d’attaque de la plupart des boutiques. Le cœur attire l’attention ; les modules tiers vieillissent discrètement. L’historique est long — l’injection SQL dans blockwishlist, l’injection de modèles côté serveur basée sur Smarty (SSTI) menant à l’exécution de code à distance dans plusieurs modules, et un flux régulier de failles moins connues. Un module installé une fois puis oublié est un point d’entrée idéal précisément parce que personne ne le surveille. Si votre liste de mises à jour de modules affiche une pile de mises à jour en attente, ou des modules d’éditeurs qui n’existent plus, traitez cela comme un signal d’alerte.
Votre administration est sur le chemin par défaut, sans limitation des tentatives ni 2FA
Un back-office accessible à une URL prévisible, sans protection contre la force brute et sans authentification à deux facteurs, est une invitation ouverte aux robots de credential stuffing et de devinette de mots de passe. Ils tournent en permanence et n’ont pas besoin d’être sophistiqués : il leur suffit d’un seul mot de passe faible ou réutilisé sur un compte employé.
Aucun WAF, et votre adresse IP d’origine est exposée
Si votre boutique est directement exposée sur Internet sans pare-feu applicatif web, chaque requête malveillante atteint votre code applicatif sans filtrage. Pire encore, si vous utilisez un CDN mais que votre vraie adresse IP d’origine fuit (dans l’historique DNS, les en-têtes d’e-mails ou un ancien sous-domaine), les attaquants peuvent contourner entièrement la protection et frapper directement le serveur.
Fichiers inexpliqués, cœur modifié ou comptes admin que vous ne reconnaissez pas
Des fichiers PHP égarés dans la racine web, des fichiers du cœur qui diffèrent d’une version propre, ou une entrée dans votre liste d’employés que personne dans l’équipe n’a créée : chacun de ces signes peut indiquer que vous avez déjà été compromis. Les portes dérobées sont conçues pour paraître banales et rester silencieuses ; elles se signalent donc rarement d’elles-mêmes.
Un tunnel de commande ou un formulaire de paiement qui « semble légèrement différent »
C’est le signe qui coûte le plus cher. Les skimmers de type Magecart injectent quelques lignes de JavaScript qui copient discrètement les données de carte pendant que les clients les saisissent, puis les envoient au serveur d’un attaquant. La page fonctionne toujours. La commande se finalise toujours. Seules les données de carte fuient. Si votre paiement vous paraît subtilement différent — un champ en plus, un décalage de mise en page, un script que vous ne vous souvenez pas avoir ajouté — prenez-le au sérieux. Nous avons expliqué précisément le fonctionnement de l’un de ces cas dans notre article anatomie d’une attaque Magecart sur un skimmer PrestaShop.
Aucune surveillance de l’intégrité des fichiers et aucune sauvegarde hors site
Si vous n’avez aucun moyen de détecter qu’un fichier a changé, vous ne pouvez pas distinguer une boutique saine d’une boutique compromise — et vous l’apprendrez généralement par un client ou par votre prestataire de paiement. Et si vos seules sauvegardes se trouvent sur le même serveur (ou si vous n’avez jamais réellement testé une restauration), une compromission ou un disque défaillant peut mettre fin à l’activité, pas seulement à la journée.
Vous stockez plus de données client que nécessaire
Chaque champ supplémentaire que vous conservez est une responsabilité que vous portez. Stocker des données complètes de carte bancaire, garder des années de données personnelles sans politique de conservation, ou journaliser des informations sensibles transforme une fuite « embarrassante » en problème PCI-DSS et RGPD avec un vrai poids financier et juridique. Les données les plus sûres sont celles que vous n’avez jamais conservées.
Un autocontrôle en 10 minutes
Avant de demander de l’aide à qui que ce soit — y compris à nous — faites vous-même cette vérification. Elle ne coûte rien et vous apprend beaucoup :
- Confirmez votre version exacte de PrestaShop et vérifiez si elle est encore prise en charge. Si c’est une 1.6.x ou une 1.7.x ancienne, vous avez déjà votre réponse.
- Ouvrez la liste des mises à jour de modules dans votre back-office et comptez les mises à jour en attente. Notez les modules provenant d’éditeurs qui ont disparu.
- Listez vos employés admin. Consultez la table
ps_employeeou la page Équipe et vérifiez que chaque compte ayant accès au back-office est bien un compte que vous reconnaissez. - Comparez vos fichiers du cœur avec une copie propre de la même version de PrestaShop. Toute modification dans
/classes,/controllersou la racine que vous n’avez pas faite mérite examen. - Triez la racine web par date de modification. Les fichiers récemment modifiés que vous ne pouvez pas expliquer sont le moyen le plus rapide de repérer une porte dérobée.
- Vérifiez que vos sauvegardes existent hors site et se restaurent réellement. Une sauvegarde que vous n’avez jamais testée est un espoir, pas une sauvegarde.
Si les six points ressortent propres, c’est réellement rassurant — et vous n’avez peut-être pas besoin de dépenser un centime. Si l’un d’eux vous met mal à l’aise, ce malaise est le signal utile.
Si vous avez un accès shell ou base de données, trois commandes en lecture seule
Elles confirment certains des contrôles ci-dessus et sont strictement en lecture seule — elles listent et comparent, elles ne changent rien. Adaptez le préfixe de table ps_ au vôtre.
# 1. List every account with back-office access — look for anyone you don't recognise
SELECT id_employee, email, lastname, firstname, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;
# 2. Spot recently-modified PHP files in the webroot (a common backdoor tell)
find /path/to/your/shop -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %p\n' \
| sort
# 3. Confirm your stored PrestaShop version, then compare it to the supported list
mysql -e "SELECT value FROM ps_configuration WHERE name='PS_VERSION_DB';"La requête sur les employés est le moyen le plus rapide de repérer un compte admin frauduleux ; une adresse e-mail inconnue ou une ligne active=1 que personne n’a créée est un signal sérieux. La commande find fait ressortir les fichiers touchés au cours des 30 derniers jours — confrontez chacun d’eux aux travaux que vous avez réellement effectués. Aucun de ces éléments ne prouve à lui seul une compromission, mais tout élément inexpliqué ici correspond exactement au « signal utile » qui mérite d’être escaladé.
La partie honnête : diagnostiquer avant d’acheter
Voici le détour que la plupart des discours de sécurité évitent. La bonne réponse à ces signes n’est presque jamais « acheter un produit ». C’est « comprendre ce qui ne va réellement pas ». Parfois, la correction relève de la configuration ou de l’hébergement — un serveur mal configuré, un WAF manquant, une origine exposée — auquel cas un audit d’hébergement est l’étape pertinente, pas un module. Parfois, il s’agit de durcissement : fermer le chemin admin, ajouter une limitation des tentatives et la 2FA, ce qui est précisément le rôle d’un module à code ouvert comme Security Revolution — mais seulement après avoir confirmé que c’est bien la faille à combler. Et parfois, il faut nettoyer, parce que quelque chose est déjà entré, ce qui constitue une mission ciblée à part entière.
C’est toute la raison pour laquelle il vaut mieux commencer par un audit de sécurité : il cartographie votre exposition réelle et vous indique laquelle de ces trois voies est la vôtre, afin que vous ne dépensiez pas d’argent pour résoudre un problème que vous n’avez pas. Vous le lancez en saisissant l’URL de votre boutique sur la page d’audit de sécurité ; un contrôle de préparation en lecture seule s’exécute sur l’URL, et l’audit n’est commandé qu’ensuite.
Si l’idée de donner des accès vous rend nerveux — elle devrait — cet instinct est le bon, et nous avons conçu le processus en conséquence. L’audit est réalisé en lecture seule : nous regardons, nous n’écrivons pas, et nous ne touchons jamais à votre base de données clients. Nous avons documenté précisément ce que cela signifie, ce à quoi nous accédons et ce à quoi nous n’accédons pas dans notre guide de préparation à l’audit de boutique, qu’il vaut la peine de lire avant de commander pour savoir exactement ce que vous acceptez. Sécurité et performance vont souvent ensemble ; si vous cartographiez déjà la santé de votre boutique, il est donc aussi utile de regarder les services experts plus larges et l’audit de performance en parallèle.
Lancez le contrôle de dix minutes aujourd’hui. S’il est propre, profitez de cette tranquillité d’esprit — elle ne vous aura rien coûté. Sinon, vous en savez maintenant assez pour poser la bonne question, ce qui vaut bien plus que n’importe quel produit isolé.
Questions fréquentes
Un audit de sécurité nettoie-t-il une infection ou se contente-t-il de la détecter ?
Un audit diagnostique : il cartographie votre exposition et vous indique si quelque chose est déjà entré. Le nettoyage est une mission séparée et ciblée, car supprimer une porte dérobée proprement signifie trouver tous les points d’entrée, pas seulement celui que vous avez remarqué, puis fermer la faille qui l’a laissé entrer pour éviter son retour. L’audit vous dit si vous avez réellement besoin d’un nettoyage, et jusqu’où il doit aller. Méfiez-vous des promesses du type « nous scannons et corrigeons tout en une seule passe » ; une porte dérobée discrète et persistante disparaît rarement aussi proprement.
J’utilise un PrestaShop 8 à jour, avec tous les modules mis à jour. Ai-je quand même besoin d’un audit ?
Peut-être pas, et c’est une bonne situation. Un cœur actuel et des modules à jour éliminent les risques les plus importants et les plus scannés. Les questions restantes auxquelles un audit répond sont celles que les mises à jour ne couvrent pas : votre IP d’origine fuit-elle derrière votre CDN, le chemin admin peut-il être attaqué par force brute, disposez-vous d’une surveillance de l’intégrité des fichiers et d’une sauvegarde hors site testée, et conservez-vous plus de données client que nécessaire ? Si l’autocontrôle de dix minutes est propre sur ces points aussi, votre situation est réellement saine.
Aurez-vous besoin de mon mot de passe admin ou d’une copie de ma base de données ?
Non. Un audit de sécurité commence avec la seule URL de votre boutique et s’exécute en grande partie depuis l’extérieur. Lorsqu’un contrôle nécessite de regarder à l’intérieur du back-office, un compte employé en lecture seule suffit, et nous ne demandons ni ne prenons jamais de copie de vos données clients ou de commandes. Le modèle d’accès complet est détaillé dans le guide de préparation à l’audit de boutique — lisez-le avant de commander pour savoir exactement ce que cela implique.
Comment distinguer une vraie compromission d’une fausse alerte dans l’autocontrôle ?
Souvent, vous ne pouvez pas le faire seul, et c’est la limite honnête d’un autocontrôle : il sert à faire remonter des signaux, pas à les confirmer. Un fichier récemment modifié peut être une mise à jour légitime ; un employé inconnu peut être un ancien prestataire. Le rôle de l’autocontrôle est de vous dire s’il faut regarder plus attentivement. Quand un élément inexpliqué apparaît et que vous ne pouvez pas le justifier, c’est le moment où une revue extérieure s’amortit, car confirmer « tout va bien » a autant de valeur que confirmer « ce n’est pas normal ».
À quelle fréquence dois-je lancer l’autocontrôle ?
La version en dix minutes est assez légère pour être lancée chaque trimestre, et après tout changement important : mise à niveau de PrestaShop, nouveau module de paiement, changement de thème ou mouvement de personnel ayant touché les accès admin. Les deux contrôles qu’il vaut mieux automatiser plutôt que répéter à la main sont la surveillance de l’intégrité des fichiers et les sauvegardes hors site testées ; une fois qu’ils tournent en continu, le reste consiste surtout à confirmer que rien n’a dérivé.
Commentaires
Aucun commentaire pour le moment. Soyez le premier !
Soyez le premier à poser une question ou à partager un retour utile.
Laisser un commentaire
Partagez une question, un détail de pose ou un retour qui pourrait aider un autre lecteur.