Sécurisation de PrestaShop : la checklist complète

Une boutique PrestaShop est une cible tentante pour une raison simple : elle se trouve au croisement de l’argent et des données personnelles, avec les flux de paiement, les noms et adresses des clients, l’historique des commandes et un panneau d’administration accessible depuis n’importe où sur Internet. La plupart des attaques qui la visent ne sont pas sophistiquées : elles sont automatisées, non ciblées et cherchent la seule case que vous avez oublié de cocher. Cette page est cette liste de cases. C’est la checklist de référence pour durcir la sécurité d’une boutique PrestaShop, classée de façon à traiter d’abord les actions les plus rentables et les plus simples, chaque sujet plus avancé renvoyant ensuite vers le guide qui l’explique correctement.

Révisé en juin 2026. Ces contrôles s’appliquent à PrestaShop 1.7, 8 et 9 (le back-office de PS9 fonctionne sous Symfony 6.4) ; nous tenons cette checklist à jour au fil des avis de sécurité et de l’évolution des dates de prise en charge de PHP.

Utilisez-la comme une checklist, pas comme un essai. Avancez de haut en bas : les éléments du niveau 1 ferment les portes que les scanners automatisés secouent tous les jours, et vous pouvez réaliser la plupart d’entre eux depuis votre back-office ou votre panneau d’hébergement en une après-midi. Si vous voulez couvrir le même terrain dans un langage très simple, sans jargon, commencez par notre guide en langage clair pour les propriétaires de boutique, puis revenez ici pour le tour complet.

Comment utiliser cette checklist

Chaque point ci-dessous est un contrôle avec un responsable clair et un bénéfice concret. Lorsqu’un contrôle mérite son propre pas-à-pas — configuration de la 2FA, règles .htaccess, SSL, blocage des bots — cette page vous donne le « quoi et pourquoi » en un paragraphe, puis renvoie vers le guide qui détaille la procédure. Cette organisation en hub est volontaire : vous obtenez ici la carte complète sans que nous réexpliquions reCAPTCHA pour la cinquième fois, et vous suivez le lien lorsque vous êtes prêt à configurer quelque chose pour de bon.

Un cadrage avant de commencer : la plupart de ces contrôles servent à réduire la surface d’attaque (moins de portes), et quelques-uns servent à détecter et récupérer lorsqu’une attaque passe malgré tout (alarmes et issues de secours). Une boutique sécurisée a besoin des deux. Une boutique avec un mot de passe administrateur de 16 caractères mais sans sauvegardes n’est qu’à une mauvaise mise à jour de module d’une semaine très compliquée.

Niveau 1 — Les indispensables (à faire cette semaine)

1. Renommez le dossier d’administration

PrestaShop installe déjà votre dossier d’administration avec un suffixe aléatoire (quelque chose comme admin8f3k2) précisément pour cette raison, mais de nombreuses boutiques mises à niveau depuis d’anciennes versions utilisent encore un /admin ou un /adminXXXX facile à deviner, que les scanners testent en premier. Renommez le dossier via FTP/SFTP ou le gestionnaire de fichiers de votre hébergeur avec un nom impossible à deviner (évitez les mots évidents comme backoffice, manage ou panel : ils sont eux aussi scannés). PrestaShop détecte le renommage à la connexion suivante ; ensuite, mettez votre favori à jour et communiquez la nouvelle URL à votre équipe. Et alors ? La principale source de trafic de force brute contre l’administration vient des bots qui martèlent les URL de connexion prévisibles. Déplacez la porte et la plupart ne la trouveront jamais.

2. Des mots de passe administrateur forts et uniques — et un ménage dans les comptes

Chaque compte du back-office doit utiliser un mot de passe long et unique (16 caractères ou plus), généré et stocké dans un gestionnaire de mots de passe, et jamais réutilisé ailleurs. Tout aussi important : ouvrez Paramètres avancés → Équipe → Employés et supprimez chaque compte qui n’a plus besoin d’accès. Le compte administrateur dormant d’un ancien freelance est une surface d’attaque pure, sans aucun bénéfice. Pendant que vous y êtes, vérifiez que personne n’a créé discrètement un compte que vous ne reconnaissez pas.

3. Forcez HTTPS partout

Faire passer le tunnel de commande et la connexion en HTTP simple en 2026 n’est pas un risque que l’on accepte, c’est un défaut que l’on corrige. HTTPS protège les identifiants, les données de carte et les informations personnelles en transit, et PrestaShop dispose d’un réglage intégré pour l’imposer dans Paramètres de la boutique → Général → Activer le SSL, puis Activer le SSL sur toutes les pages. Si vous n’avez pas encore installé de certificat et forcé HTTPS sur tout le site, suivez notre guide de configuration SSL et HTTPS : il couvre l’installation du certificat, les deux interrupteurs PrestaShop et la correction des alertes de contenu mixte qui piègent souvent les marchands.

4. Gardez PrestaShop et PHP à jour

L’immense majorité des boutiques PrestaShop compromises utilisaient une version présentant une vulnérabilité publique, connue et déjà corrigée. Restez sur une version prise en charge, abonnez-vous aux avis de sécurité de PrestaShop et n’exécutez jamais une version de PHP en fin de vie (7.4 et 8.0 ont toutes deux dépassé leurs dates de support de sécurité). Avant toute mise à niveau du noyau : faites une sauvegarde complète, testez sur une copie de préproduction et confirmez que vos modules sont compatibles. Et alors ? Appliquer les correctifs n’a rien de spectaculaire, mais « nous avions une version de retard » est la phrase la plus fréquente dans les analyses post-incident.

5. Réduisez ce que vos pages d’erreur et vos en-têtes révèlent

Assurez-vous que le mode debug est désactivé en production : confirmez que _PS_MODE_DEV_ vaut false dans config/defines.inc.php, et vérifiez que Paramètres avancés → Performance → Mode debug est désactivé, afin qu’une trace d’erreur ne livre jamais à un attaquant vos chemins de fichiers, votre préfixe de tables ou les versions de vos bibliothèques. Une page de debug exposée est une carte gratuite de votre installation.

Niveau 2 — Contrôle des accès

6. Activez l’authentification à deux facteurs pour le back-office

La 2FA signifie qu’un mot de passe administrateur volé ne suffit pas à se connecter : l’attaquant a aussi besoin du code sur votre téléphone. Cela bloque en une seule mesure le bourrage d’identifiants et l’hameçonnage, et c’est le contrôle d’accès le plus rentable que vous puissiez ajouter. La configuration complète, y compris les politiques de mot de passe et le durcissement des sessions, fait l’objet de son propre guide : authentification à deux facteurs, politiques de mot de passe et sécurité de l’administration pour PrestaShop.

7. Limitez le rythme des connexions échouées et verrouillez les comptes

Les outils de force brute essaient des milliers de mots de passe. Mettez-leur un plafond : déclenchez un verrouillage temporaire après quelques tentatives échouées (une politique courante consiste à verrouiller 15 minutes après cinq échecs, puis à appliquer un verrouillage long ou un bannissement IP après vingt). PrestaShop ne bride pas fortement les connexions administrateur par lui-même ; cela se gère donc généralement au niveau du WAF, de la périphérie réseau ou avec un module de sécurité.

8. Restreignez l’accès à l’administration par IP

Si votre équipe se connecte depuis des adresses fixes (bureau, domicile, sortie VPN), limitez le dossier d’administration à ces IP avec une règle .htaccess (Require ip ... sur Apache) ou votre pare-feu. Ce contrôle élimine directement l’essentiel du trafic de force brute et de bourrage d’identifiants, car les requêtes de l’attaquant n’atteignent jamais le formulaire de connexion. Les règles exactes se trouvent dans notre guide de sécurité et de performance .htaccess.

9. Resserrez les droits des employés

Le système de profils de PrestaShop dans Paramètres avancés → Équipe → Permissions est granulaire : utilisez-le. Un rédacteur n’a pas besoin de gérer les modules ; un agent du service client n’a pas besoin des réglages serveur ni du gestionnaire SQL. Donnez à chaque profil le minimum nécessaire, puis réauditez régulièrement la liste des employés et retirez les personnes parties. Le moindre privilège signifie qu’un seul compte salarié compromis ne peut pas faire tomber toute la boutique.

Niveau 3 — Durcissement du serveur et des fichiers

Sur nginx, l’équivalent est une règle de refus pour les dossiers applicatifs sensibles et les fichiers PHP téléversés. Les chemins varient selon l’hébergement, donc testez d’abord avec nginx -t et une requête sur une préproduction.

location ~* ^/(app|var|vendor|config|classes|controllers|override)/ {
    deny all;
}

location ~* /(img|upload)/.*\.php$ {
    deny all;
}

Les règles serveur et les en-têtes de sécurité doivent être vérifiés ensemble après le durcissement.

10. Définissez les bons droits fichiers

Les dossiers doivent être en 755, les fichiers en 644. Rien dans une installation PrestaShop ne doit jamais être en 777 (accessible en écriture à tout le monde) : si un tutoriel vous dit de faire un chmod 777 pour « que ça marche », c’est le tutoriel qui est le problème. Les fichiers modifiables par tous sont exactement ce dont une faille de téléversement a besoin pour déposer une porte dérobée.

11. Bloquez l’accès web direct aux dossiers sensibles

Plusieurs dossiers PrestaShop ne devraient jamais être accessibles depuis un navigateur : /app/, /cache/, /config/, /var/, /vendor/, /translations/, /mails/ et les équivalents. Le .htaccess fourni par PrestaShop en couvre certains, mais vérifiez-les et ajoutez ce qui manque (et confirmez que Options -Indexes est défini afin que l’indexation des répertoires soit désactivée, faute de quoi elle expose votre liste exacte de modules à n’importe quel curieux). L’ensemble complet des règles — dossiers sensibles, listing, dotfiles — se trouve dans le guide de sécurité et de performance .htaccess.

12. Ajoutez des en-têtes de sécurité HTTP

Les en-têtes de sécurité indiquent au navigateur d’activer des protections supplémentaires. Le lot le plus utile pour une boutique PrestaShop : X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN (anti-clickjacking), Strict-Transport-Security (à ajouter seulement une fois HTTPS parfaitement en place — voir le point 3), Referrer-Policy: strict-origin-when-cross-origin, et une Content-Security-Policy déployée d’abord en mode report-only pour ne pas casser les scripts de votre propre thème. La CSP, en particulier, est votre meilleure défense contre un skimmer de carte qui injecte un script malveillant dans le tunnel de commande — c’est exactement le déroulé de l’attaque expliquée dans notre guide anatomie d’une attaque de type Magecart sur PrestaShop.

13. Placez un WAF devant la boutique

Un pare-feu d’application web filtre le trafic malveillant avant qu’il ne touche PrestaShop. L’offre gratuite de Cloudflare bloque de nombreux schémas courants et ajoute une protection DDoS ; Cloudflare Pro et ModSecurity (avec l’OWASP Core Rule Set) vont plus loin. Un WAF est aussi votre première ligne de défense contre la pression volumétrique et celle générée par les robots d’exploration, y compris le flot ?q= de la recherche à facettes, qui peut discrètement transformer les propres URL de filtres de PrestaShop en déni de service auto-infligé ; nous le décortiquons et le controns avec des règles Cloudflare dans survivre au flot ?q=.

Niveau 4 — Hygiène des modules et des API

14. Auditez les modules installés sans complaisance

Chaque module est du code qui s’exécute dans votre boutique, et chaque module inutilisé est un risque sans bénéfice. Trois règles : supprimez tout ce que vous n’utilisez pas activement (désactivé ne suffit pas : les fichiers PHP restent accessibles) ; n’exécutez jamais de modules nulled (piratés), qui embarquent régulièrement des portes dérobées ; et gardez tout à jour en consultant les avis de sécurité sur le site du développeur. Après un noyau non corrigé, les modules tiers obsolètes sont le vecteur de compromission le plus fréquent sur PrestaShop.

15. Verrouillez ou désactivez l’API Webservice

Si vous utilisez l’API Webservice de PrestaShop (Paramètres avancés → Webservice), donnez à chaque clé uniquement les ressources minimales nécessaires plutôt qu’un accès complet, supprimez les clés inutilisées, exigez HTTPS et restreignez par IP lorsque c’est possible. Si vous ne l’utilisez pas, passez Activer le service web de PrestaShop à Non. Une clé API trop permissive est une exportation complète de données en attente de se produire.

16. Supprimez les données par défaut et de démonstration

Les produits de démonstration, catégories d’exemple et pages CMS par défaut qui traînent encore ne servent à rien et donnent des indices sur l’âge et la structure de votre installation. Supprimez-les une fois la boutique réelle.

Niveau 5 — Abus côté front-office et contrôle des bots

17. Stoppez le spam dans les formulaires avec reCAPTCHA

Formulaires de contact, création de compte, avis et inscriptions à la newsletter sont les portes par lesquelles les bots entrent pour inonder votre boutique de contenu indésirable et chercher des faiblesses. reCAPTCHA arrête le bruit automatisé sans bloquer les vrais clients, avec une configuration adaptée à PrestaShop dans notre guide reCAPTCHA pour PrestaShop.

18. Bloquez les mauvais bots et les visiteurs abusifs

Au-delà du CAPTCHA, vous devez filtrer le trafic qui n’a rien à faire sur votre boutique : robots d’aspiration, scanners de vulnérabilités et clients qui martèlent les points d’accès. L’application réelle des règles contre les bots hostiles se fait au niveau d’un WAF, de règles serveur ou d’un module de sécurité dédié, pas dans les réglages du noyau de PrestaShop ; Paramètres de la boutique → Trafic & SEO aide seulement avec robots.txt et les indications données aux robots d’exploration, que les bots bien élevés respectent mais que les scanners ignorent. La géolocalisation peut restreindre des pays entiers, mais ce n’est pas non plus un contrôle anti-scanner. La boîte à outils complète se trouve dans contrôle des visiteurs : bloquer les mauvais bots et le trafic indésirable. Pour traiter des récidivistes précis par IP — le client qui passe sans cesse des commandes frauduleuses, l’adresse qui continue de sonder — consultez informations client supplémentaires et bannissements IP.

19. Protégez par mot de passe ce qui n’est pas prêt pour le public

Contenu de préproduction, pages grossistes, collection non publiée : tout ce qui est en ligne mais ne doit pas encore être indexé ni consulté doit être placé derrière un mot de passe plutôt que de dépendre d’une URL obscure. Les approches pour PrestaShop sont détaillées dans protection par mot de passe pour PrestaShop.

Niveau 6 — Supervision, réponse et restauration

20. Surveillance de l’intégrité des fichiers

Le moyen le plus rapide de repérer une compromission est de remarquer immédiatement qu’un fichier qui ne devrait pas changer vient d’être modifié. La surveillance de l’intégrité des fichiers (FIM) calcule l’empreinte de vos fichiers PrestaShop et de vos modules, puis vous alerte lorsqu’un fichier est modifié de façon inattendue — exactement ce qui se produit dès qu’un attaquant injecte du code dans un contrôleur ou un modèle de paiement. C’est le système d’alerte précoce qui transforme une compromission silencieuse en correction le jour même.

21. Surveillez vos journaux d’accès

Examinez les journaux d’accès serveur pour repérer les signaux : rafales de requêtes depuis une même IP, accès répétés à la connexion administrateur, requêtes vers des fichiers inexistants (recherche de vulnérabilités) et POST inattendus. Si votre hébergeur propose fail2ban, branchez-le sur vos journaux PrestaShop afin que les récidivistes soient bannis automatiquement. Savoir à quoi ressemble la normale permet de repérer l’anormal.

22. Supervision de disponibilité et de certificat

Un outil gratuit comme UptimeRobot, qui surveille les indisponibilités, l’expiration SSL et les pics soudains de temps de réponse, remplit deux rôles : il détecte les pannes et signale aussi l’épuisement de ressources provoqué, par exemple, par une charge de cryptominage ou un flot de trafic avant que vos clients ne s’en aperçoivent.

23. Sauvegardes automatisées, testées et hors site

Sauvegardez les fichiers et la base de données tous les jours, conservez des copies à au moins deux endroits (serveur plus cloud hors site) et — c’est la partie que tout le monde saute — testez réellement une restauration chaque trimestre. Une sauvegarde que vous n’avez jamais restaurée est un espoir, pas un plan. Chiffrez les sauvegardes de base de données hors site (elles contiennent des données clients) avec GPG. Conservez par exemple 30 jours de sauvegardes quotidiennes et quelques mois d’hebdomadaires ; le stockage coûte peu, et un point de restauration propre est ce qui vous évite de repartir de zéro.

24. Rédigez le plan de réponse à incident avant d’en avoir besoin

Lorsqu’une boutique est compromise, le pire moment pour chercher la prochaine étape est à 2 h du matin. Documentez-la à l’avance : qui appeler (hébergeur, prestataire de paiement, spécialiste sécurité), comment passer en mode maintenance sans perdre les commandes en cours, où se trouve la dernière sauvegarde saine, comment la restaurer et quoi vérifier ensuite. Si le pire est déjà arrivé, notre guide de réponse à une violation de données déroule toute la séquence pas à pas, obligations de notification RGPD comprises.

Le cas particulier : une boutique que vous ne pouvez pas encore mettre à niveau

La checklist ci-dessus suppose que vous pouvez appliquer les correctifs. Beaucoup de vraies boutiques ne le peuvent pas : thème fortement personnalisé, module critique sans version compatible, migration de plateforme prévue dans six mois. Cela ne veut pas dire que vous êtes sans défense. Le correctif virtuel, les règles WAF en périphérie et le durcissement ciblé peuvent protéger une vulnérabilité connue sans toucher au noyau, le temps de faire une mise à niveau propre. Le mode opératoire complet pour les boutiques bloquées sur une ancienne version est durcissement avancé de PrestaShop pour les boutiques que vous ne pouvez pas encore mettre à niveau.

Où les modules ont leur place — et où ils ne l’ont pas

La majeure partie de cette checklist ne coûte rien d’autre que de l’attention : réglages déjà disponibles dans le back-office, interrupteurs du panneau d’hébergement, une heure avec votre .htaccess. Nous préférons que vous fassiez cela plutôt que d’acheter quoi que ce soit. Un module mérite sa place pour les points qui sont pénibles ou impossibles à faire manuellement : principalement la 2FA et le durcissement des connexions, ainsi que la surveillance continue de l’intégrité des fichiers, qui suit chaque modification à votre place au lieu de vous obliger à examiner les journaux à l’œil. Nos modules de sécurité sur mypresta.rocks couvrent ces couches, configurées depuis votre back-office sans modifier le noyau, afin qu’une mise à niveau ne les annule pas. Et alors ? Vous payez pour automatiser les contrôles qu’un humain ne peut pas suivre manuellement en continu, pas pour remplacer l’hygiène gratuite qui fait l’essentiel du travail.

Le résumé honnête

La sécurité sur PrestaShop n’est pas un projet que l’on termine ; c’est un niveau d’exigence que l’on maintient. La bonne nouvelle, c’est que les attaques qui visent votre boutique sont pour la plupart simples et automatisées, ce qui signifie que les contrôles basiques et peu spectaculaires — appliquer les correctifs, renommer l’administration, forcer HTTPS, utiliser des mots de passe forts, activer la 2FA, tester réellement les sauvegardes — arrêtent l’immense majorité d’entre elles. Descendez cette liste, ouvrez les guides détaillés à mesure que vous arrivez à chaque contrôle, et ajoutez un rappel trimestriel récurrent dans votre calendrier pour la repasser. Les boutiques compromises sont presque toujours celles qui avaient l’intention de faire les choses ennuyeuses, pas celles qui les ont faites.

Contrôle rapide : lister tous les comptes du back-office en une requête

Le point 2 vous demande d’alléger la liste des employés et de vérifier que personne n’a créé discrètement un compte que vous ne reconnaissez pas. Le back-office vous montre cela dans Paramètres avancés → Équipe → Employés, mais une requête SQL en lecture seule est plus rapide à parcourir et plus difficile à masquer par une interface d’administration altérée. Exécutez-la sur votre base de données (ajustez le préfixe ps_ pour qu’il corresponde au vôtre) : elle lit seulement, elle ne modifie rien.

-- Read-only: every back-office account, newest first.
-- Flag SuperAdmins (id_profile = 1) you don't recognise, and any
-- account whose date_add is recent but that nobody on your team created.
SELECT id_employee, email, id_profile, active, date_add, last_connection_date
FROM ps_employee
ORDER BY date_add DESC;

Deux lignes méritent un second examen : tout id_profile = 1 (SuperAdmin) inattendu, et tout compte dont le date_add tombe dans une période où vous n’intégriez pas de nouveaux collaborateurs. Un SuperAdmin malveillant créé pendant une compromission est l’une des premières choses qu’un attaquant installe pour conserver une porte de retour, et il survit à un nettoyage de malware si vous ne faites que supprimer les fichiers infectés. Désactivez-le dans le back-office plutôt que de le supprimer si vous voulez d’abord le conserver comme preuve.

Questions fréquentes

Je suis une petite boutique sans développeur. Quelle part de cette checklist puis-je vraiment faire moi-même ?

La majeure partie des niveaux 1 et 2 — renommer le dossier d’administration, utiliser des mots de passe forts, forcer HTTPS, activer la 2FA, supprimer les comptes inutiles, resserrer les permissions — relève du back-office ou du panneau d’hébergement et ne demande aucun code. Les éléments côté serveur (droits fichiers, .htaccess, en-têtes) sont ceux pour lesquels il est raisonnable de solliciter votre hébergeur ou un développeur. Commencez par la version en langage clair dans notre guide pour les propriétaires de boutique, puis descendez la liste à partir de là.

Ai-je besoin d’un module de sécurité, ou le durcissement gratuit suffit-il ?

Le durcissement gratuit fait l’essentiel du travail et vous devriez le faire en premier dans tous les cas. Un module ne mérite sa place que pour deux tâches pénibles ou impossibles à faire à la main : la 2FA avec le durcissement des connexions, et la surveillance continue de l’intégrité des fichiers, qui suit chaque modification au lieu de vous obliger à examiner les journaux à l’œil. Si vous payez, vous payez pour automatiser cela, pas pour remplacer les fondamentaux gratuits.

L’offre gratuite de Cloudflare suffit-elle comme WAF ?

Pour une boutique typique, elle bloque beaucoup de sondes courantes et ajoute une protection DDoS, donc elle vaut la peine d’être activée. Mais l’offre Free ne permet pas de faire correspondre les chaînes de requête ni les user-agents dans les règles de limitation de débit, ce qui compte si vous êtes activement ciblé : par exemple, freiner un flot ?q= de recherche à facettes nécessite Pro. Nous expliquons précisément où Free atteint ses limites dans le durcissement avancé pour les boutiques que vous ne pouvez pas encore mettre à niveau.

À quelle fréquence dois-je repasser cette checklist ?

Ajoutez un rappel trimestriel récurrent dans votre calendrier : vingt minutes pour confirmer que PrestaShop et les modules sont corrigés, que la 2FA est active pour tout le monde, que les comptes d’anciens employés ont disparu et qu’une sauvegarde se restaure réellement. La sécurité sur PrestaShop n’est pas un projet que l’on termine ; c’est un niveau d’exigence que l’on maintient.

Ma boutique est sur une version que je ne peux pas mettre à niveau maintenant. Suis-je simplement exposé ?

Non, mais vous passez des correctifs classiques aux correctifs virtuels : règles WAF en périphérie, verrouillage de l’origine pour empêcher les attaquants de la contourner, et corrections ciblées pour les failles précises citées par vos journaux et les avis de sécurité. Le mode opératoire complet pour les boutiques bloquées sur une ancienne version est le durcissement avancé de PrestaShop pour les boutiques que vous ne pouvez pas encore mettre à niveau.

À lire ensuite

• Sécuriser votre boutique PrestaShop : un guide en langage clair pour les propriétaires de boutique — le même terrain sans jargon, pour les propriétaires non techniques.
• Anatomie d’une attaque de type Magecart sur une boutique PrestaShop 1.7.x — ce contre quoi ces contrôles vous protègent réellement, vu de l’intérieur.
• Réponse à une violation de données : que faire si votre boutique est piratée — le mode opératoire calme et pas à pas pour les premières heures.