Le back-office PrestaShop concentre les données clients, les commandes, les moyens de paiement configurés et les droits de gestion de la boutique. Sa protection ne repose pas sur un unique module : elle combine un accès HTTPS fiable, des comptes individuels, des permissions limitées, une authentification renforcée et une maintenance régulière. L’objectif est de réduire les tentatives d’intrusion, mais aussi de limiter les conséquences si un identifiant est compromis.
Commencer par cartographier les accès administrateur
Avant de modifier la configuration, listez les personnes et les services qui accèdent à l’administration : dirigeant, salariés, préparateur de commandes, agence, développeur, comptable ou prestataire marketing. Dans Paramètres avancés > Équipe (le libellé peut varier selon la version), chaque intervenant doit disposer de son propre compte. Un compte générique du type admin@boutique.fr partagé par plusieurs personnes empêche d’identifier l’auteur d’une action et complique la révocation d’un accès.
Supprimez ou désactivez immédiatement les comptes d’anciens salariés, de prestataires dont la mission est terminée et les comptes de test. Vérifiez également les adresses e-mail associées : elles doivent être fonctionnelles, car elles servent notamment aux procédures de réinitialisation de mot de passe.
Appliquer le principe du moindre privilège
Créez des profils correspondant à des tâches réelles, puis attribuez-les aux employés. Par exemple, un préparateur de commandes peut avoir besoin de consulter et mettre à jour les commandes, sans pouvoir installer un module, modifier les transporteurs ou accéder aux paramètres de paiement. Une personne chargée du catalogue n’a pas nécessairement besoin des droits sur les clients, les employés ou les réglages avancés.
Évitez d’attribuer le profil SuperAdmin par défaut. Réservez-le à un nombre très limité de responsables techniques. Contrôlez particulièrement les droits de création, modification et suppression sur les modules, les employés, les webservices, les préférences et les méthodes de paiement : ce sont des zones où une erreur ou un accès malveillant peut avoir un impact étendu.
Rendre l’URL d’administration moins exposée
PrestaShop utilise un répertoire d’administration distinct, souvent nommé avec un suffixe aléatoire après l’installation, par exemple /admin847xk/. Ne le renommez pas en /admin/ et ne communiquez pas cette URL publiquement. Si le dossier est ancien, prévisible ou connu d’anciens prestataires, son renommage peut réduire le bruit des scans automatisés.
Cette mesure n’est toutefois pas une protection suffisante : une URL peut être découverte dans des historiques, des journaux, des sauvegardes ou par une personne ayant déjà eu accès au site. Après renommage, mettez à jour les favoris des utilisateurs et vérifiez l’accès aux ressources du back-office. Testez aussi les opérations courantes, notamment l’ajout d’images produit et les actions AJAX, avant toute intervention sur la boutique en production.
Ajouter une barrière avant la page de connexion
La restriction réseau est très efficace lorsque les administrateurs travaillent depuis des adresses IP fixes ou un VPN. L’idée est de bloquer l’accès au répertoire d’administration au niveau du serveur web, avant même que PrestaShop ne traite la demande. Il faut toutefois prévoir les adresses du bureau, du VPN et les éventuels administrateurs nomades, sous peine de se verrouiller soi-même hors du back-office.
Exemple Apache : autoriser uniquement certaines IP
Sur Apache 2.4, une règle placée dans la configuration du virtual host ou dans un fichier .htaccess autorisé pour le dossier d’administration peut prendre cette forme :
<RequireAll>
Require all denied
Require ip 203.0.113.24
Require ip 198.51.100.0/24
</RequireAll>Les adresses ci-dessus sont des exemples réservés à la documentation : remplacez-les par vos IP réelles. L’hébergeur peut interdire ou limiter l’usage de .htaccess ; dans ce cas, demandez l’application de la règle dans la configuration serveur. Si votre site est derrière un CDN ou un proxy inverse, configurez correctement la remontée de l’IP visiteur côté serveur. Sans cela, une règle IP peut bloquer tout le monde ou ne filtrer que l’adresse du proxy.
Protection par mot de passe HTTP ou VPN
Une authentification HTTP Basic devant le dossier d’administration ajoute une seconde demande d’identifiants. Sous Nginx, elle se configure généralement avec auth_basic et un fichier htpasswd dans le bloc correspondant au répertoire admin. Cette couche est pertinente pour un petit nombre d’utilisateurs, à condition de gérer les départs et de conserver les identifiants dans un gestionnaire de mots de passe. Un VPN est plus adapté quand l’équipe accède régulièrement au back-office depuis des réseaux variés.
Ne protégez pas aveuglément l’ensemble du site par cette méthode : ciblez le répertoire d’administration. Après configuration, contrôlez les téléchargements de fichiers, les aperçus et les connexions depuis chaque environnement autorisé.
Imposer des identifiants robustes et une seconde vérification
Chaque compte doit utiliser un mot de passe long, unique et généré par un gestionnaire de mots de passe. La réutilisation d’un mot de passe déjà employé sur une messagerie, un outil SaaS ou un autre site transforme une fuite externe en risque direct pour la boutique. Changez immédiatement les mots de passe après un départ, un doute sur un poste de travail ou une compromission d’une boîte e-mail liée à un compte administrateur.
Ajoutez une authentification multifacteur pour les comptes à privilèges lorsque votre version, votre module ou votre solution d’identité le permet. PrestaShop ne doit pas être considéré comme doté d’une authentification à deux facteurs universelle et identique sur toutes les versions : vérifiez précisément la compatibilité du module choisi avec votre version de PrestaShop et de PHP. Préférez les applications d’authentification ou les clés de sécurité aux codes reçus par SMS lorsque c’est possible. Testez les codes de secours et définissez une procédure de récupération d’accès détenue par au moins deux responsables autorisés.
Maintenir PrestaShop, les modules et le serveur
Un écran de connexion bien protégé ne compense pas une faille dans un module installé. Tenez à jour le cœur de PrestaShop, les modules, le thème et la version de PHP compatible. Consultez les notes de version et les alertes de sécurité des éditeurs concernés. Avant une mise à jour, réalisez une sauvegarde testée des fichiers et de la base de données, puis reproduisez l’opération sur une préproduction lorsque la boutique utilise un thème sur mesure ou de nombreux modules.
Supprimez les modules, thèmes et overrides inutilisés plutôt que de les laisser désactivés. Un module désactivé mais présent sur le serveur reste un composant à auditer et peut contenir des fichiers exposés. N’installez pas de modules provenant de sources inconnues ou de copies non officielles : vérifiez l’éditeur, la compatibilité, la fréquence des mises à jour et le support disponible.
Éviter les permissions de fichiers dangereuses
Les permissions 777 ne sont pas une solution normale à un problème d’écriture. Elles permettent une écriture beaucoup trop large sur un hébergement classique. Les droits exacts dépendent du serveur et de son utilisateur PHP, mais le principe reste le même : les fichiers ne doivent être modifiables que par le propriétaire ou le processus nécessaire, et seuls les répertoires qui doivent réellement recevoir des fichiers doivent être inscriptibles. Faites corriger la propriété des fichiers par l’hébergeur si nécessaire plutôt que d’ouvrir tous les droits.
Réduire les vecteurs de compromission indirects
Le compte d’hébergement, le FTP/SFTP, le panneau d’administration, la base de données et la messagerie associée à PrestaShop sont aussi sensibles que le back-office. Utilisez SFTP ou SSH plutôt que FTP, activez la double authentification sur le compte hébergeur lorsqu’elle est proposée et limitez les accès de base de données. Désactivez le mode développement en production : il peut afficher des informations techniques utiles à un attaquant et ne doit servir qu’au diagnostic temporaire.
Protégez également les postes de travail des administrateurs : système et navigateur à jour, verrouillage de session, antivirus ou protection gérée selon le contexte, et absence d’extensions navigateur douteuses. Une session PrestaShop ouverte sur un ordinateur partagé ou infecté rend inutiles une partie des protections côté serveur.
Surveiller les événements et préparer la réaction
Consultez régulièrement les journaux du serveur, du pare-feu applicatif éventuel et les traces d’activité disponibles dans PrestaShop. Recherchez les échecs de connexion répétés, les connexions à des horaires ou depuis des pays inattendus, la création de nouveaux employés, l’installation de modules non planifiés ou des modifications de coordonnées de paiement.
En cas de suspicion, ne vous limitez pas à changer le mot de passe du compte administrateur. Coupez les accès concernés, réinitialisez les identifiants du back-office, de l’hébergement, SFTP, base de données et e-mails selon leur exposition, puis examinez les fichiers et les journaux. Conservez une copie des éléments utiles avant nettoyage, vérifiez les comptes employés et modules récemment modifiés, puis rétablissez la boutique depuis une sauvegarde saine si l’intégrité des fichiers ou de la base n’est plus garantie.
Faut-il changer le nom du dossier admin après chaque mise à jour PrestaShop ?
Non. Le renommage est utile si le nom est prévisible ou a été diffusé, mais il n’a pas besoin d’être répété à chaque mise à jour. Conservez une URL non évidente et protégez-la surtout par des comptes individuels, une restriction réseau ou une authentification supplémentaire.
Peut-on limiter l’accès au back-office à une adresse IP avec une IP dynamique ?
C’est possible, mais peu pratique : l’adresse peut changer et vous bloquer. Un VPN doté d’une IP fixe, une authentification HTTP supplémentaire ou une authentification multifacteur constituent généralement de meilleures options pour les collaborateurs mobiles.
Un module de sécurité peut-il remplacer les mises à jour de PrestaShop ?
Non. Un module peut compléter la protection par de la détection, du filtrage ou de l’authentification renforcée, mais il ne corrige pas les vulnérabilités du cœur, des autres modules, du thème ou du serveur. Les mises à jour restent indispensables.
Pourquoi éviter d’utiliser le même compte SuperAdmin à plusieurs ?
Un compte partagé ne permet pas d’attribuer une action à une personne précise et son mot de passe doit être changé pour tous dès qu’un intervenant part. Des comptes nominatifs avec des droits limités simplifient l’audit et la révocation.
Que vérifier après avoir installé une restriction Apache ou Nginx sur l’administration ?
Testez la connexion depuis chaque réseau autorisé, la déconnexion, la réinitialisation de mot de passe, l’ajout de médias, les actions sur les commandes et les écrans utilisant des requêtes AJAX. Gardez un accès d’urgence documenté, par exemple via le VPN ou l’hébergeur.