Une boutique PrestaShop traite des comptes clients, des commandes, des données personnelles et parfois des flux de paiement. Sa protection ne dépend pas d’un seul module de sécurité : elle repose sur un hébergement correctement administré, un cœur PrestaShop maintenu, des accès limités et une capacité réelle à restaurer le site. Cette checklist permet de sécuriser une boutique existante ou de contrôler une installation avant sa mise en production.
Commencer par un hébergement et un environnement maintenus
La sécurité applicative ne compense pas un serveur obsolète. Vérifiez que l’hébergeur maintient le système, le serveur web, PHP, la base de données et les services associés. La version de PHP doit être compatible avec votre version précise de PrestaShop, mais également encore prise en charge par PHP. Une version compatible mais arrivée en fin de vie ne reçoit plus de correctifs de sécurité.
- Activez un certificat TLS valide et forcez HTTPS sur la boutique et le back-office depuis Paramètres de la boutique > Général. Contrôlez ensuite qu’aucune ressource image, script ou feuille de style n’est appelée en HTTP.
- Utilisez des identifiants distincts pour le compte d’hébergement, SFTP/SSH, la base de données et PrestaShop. Évitez de réutiliser le mot de passe d’une boîte e-mail ou d’un autre service.
- Privilégiez SFTP ou SSH à FTP. Si un accès FTP existe encore, désactivez-le lorsque cela est possible.
- Vérifiez que les sauvegardes serveur sont stockées sur un emplacement distinct de la boutique. Une sauvegarde conservée uniquement dans le même compte d’hébergement peut disparaître avec le site.
Les droits de fichiers doivent suivre le principe du moindre privilège. Dans la plupart des environnements Linux, les fichiers sont en 644 et les dossiers en 755, avec un propriétaire cohérent avec l’utilisateur exécutant PHP. Les permissions 777 ne sont pas une correction durable d’un problème d’écriture : elles exposent inutilement les fichiers. Les besoins d’écriture de PrestaShop concernent notamment certains répertoires de cache, d’images et de téléchargement ; identifiez-les au lieu d’ouvrir toute l’arborescence.
Mettre à jour PrestaShop sans risquer la production
Les correctifs de sécurité du cœur, des modules et des thèmes sont essentiels. Toutefois, une mise à jour directement sur une boutique active peut casser un tunnel de commande, un thème surchargé ou une connexion à un transporteur. Le bon processus est donc : inventaire, sauvegarde, test sur une préproduction, puis déploiement contrôlé.
- Relevez la version de PrestaShop, de PHP, des modules actifs et du thème. Dans le back-office, consultez les notifications et l’état des mises à jour.
- Créez une copie de la boutique sur un sous-domaine ou un environnement isolé, avec une base de données de test. Désactivez l’envoi réel d’e-mails et les moyens de paiement réels sur cette copie.
- Effectuez une sauvegarde restaurable des fichiers et de la base de données. Testez au moins une fois la restauration sur un environnement de test.
- Mettez à jour, videz le cache, puis testez la connexion client, le panier, la création de compte, le paiement, les e-mails transactionnels et le retour de commande.
- Planifiez l’intervention en période creuse et surveillez les journaux après la mise en production.
N’installez pas un module uniquement parce qu’il promet de « sécuriser » PrestaShop. Téléchargez les modules et thèmes depuis une source identifiée, vérifiez leur compatibilité avec votre version et supprimez ceux qui ne sont plus utilisés. Un module désactivé mais conservé sur le serveur peut rester accessible ou être réactivé par erreur ; après sauvegarde, désinstallez-le et retirez ses fichiers si la procédure du module le permet.
Verrouiller le back-office et les comptes employés
Le back-office est une cible prioritaire, car un compte administrateur permet de modifier les prix, les coordonnées de paiement, les modules ou les redirections. Chaque personne doit disposer de son propre compte employé : un compte partagé empêche d’attribuer une action et rend la révocation impossible sans bloquer toute l’équipe.
Réduire la surface d’accès
- Supprimez ou désactivez immédiatement les comptes des prestataires, stagiaires ou anciens salariés qui n’interviennent plus.
- Attribuez un profil limité aux préparateurs de commandes, au service client ou à la comptabilité. Ne donnez pas les droits de gestion des modules, des employés ou des paramètres avancés sans nécessité.
- Utilisez des mots de passe longs, uniques et enregistrés dans un gestionnaire de mots de passe. Ne transmettez jamais un accès administrateur par e-mail non protégé.
- Ajoutez une authentification à deux facteurs si votre version ou une extension maintenue le permet. Elle est particulièrement utile pour les comptes disposant de droits élevés.
Le dossier d’administration de PrestaShop porte un nom spécifique, souvent créé ou renommé lors de l’installation. Le rendre moins prévisible limite le bruit des scans automatisés, mais ce n’est pas une protection suffisante. Une restriction d’accès par adresse IP au niveau du serveur ou d’un outil d’accès HTTP est efficace si les administrateurs disposent d’adresses IP fixes ou d’un VPN. Attention : prévoyez une procédure de secours pour les accès mobiles ou les interventions d’urgence, afin de ne pas vous bloquer vous-même.
Protéger les données, le paiement et les e-mails
Ne stockez jamais de numéros de carte bancaire dans PrestaShop, dans un fichier CSV ou dans les notes de commande. Utilisez un prestataire de paiement qui héberge la saisie sensible sur son infrastructure ou qui fournit une intégration conforme à ses exigences. Après chaque mise à jour du module de paiement, réalisez une commande de test et contrôlez les retours serveur, les remboursements et les changements de statut.
Accordez aussi une attention aux exports clients et commandes. Un export CSV contient souvent noms, e-mails, adresses et numéros de téléphone. Limitez les droits d’export, stockez ces fichiers hors du répertoire web lorsqu’ils doivent être conservés et supprimez-les après usage. Les comptes e-mail utilisés pour les notifications de commande doivent eux aussi être protégés par un mot de passe unique et, si disponible, une double authentification.
Configurez correctement l’envoi e-mail de la boutique avec un service SMTP authentifié plutôt qu’avec une fonction d’envoi non maîtrisée. Cela ne remplace pas la sécurité de PrestaShop, mais évite les erreurs d’expédition et facilite le suivi en cas de comportement anormal. Vérifiez les destinataires configurés pour les nouvelles commandes et les alertes : une adresse obsolète peut exposer des informations commerciales à un ancien collaborateur.
Prévenir les modifications malveillantes et les attaques courantes
Un pare-feu applicatif (WAF) fourni par l’hébergeur, un CDN ou une solution spécialisée peut filtrer une partie des requêtes malveillantes, des scans et des tentatives de surcharge. Configurez-le progressivement : une règle trop agressive peut bloquer le paiement, les webhooks d’un transporteur ou les appels d’un ERP. Placez en liste blanche les IP et chemins documentés par vos prestataires uniquement après avoir vérifié leur légitimité.
Surveillez les éléments qui sont souvent modifiés lors d’une compromission : fichiers PHP récemment ajoutés, fichiers modifiés dans le thème, répertoires de modules inconnus, tâches planifiées et comptes employés. Comparez les fichiers du cœur avec l’archive officielle correspondant exactement à votre version avant de supprimer un fichier suspect. Évitez de modifier directement le cœur : les corrections seront difficiles à conserver à la prochaine mise à jour et les écarts compliqueront l’audit.
Contrôles à planifier chaque mois
- Vérifier les mises à jour du cœur, des modules, du thème et de PHP.
- Contrôler la liste des employés et leurs profils d’autorisation.
- Consulter les journaux serveur, les erreurs PrestaShop et les alertes de votre hébergeur.
- Tester une sauvegarde sur un environnement séparé, pas seulement sa création.
- Passer une commande de test après toute modification importante du thème, du paiement ou du cache.
Préparer une procédure de réponse à incident
En cas de redirection inconnue, de création de comptes administrateurs, d’envoi d’e-mails anormal ou de fichiers suspects, évitez de « nettoyer » au hasard. Placez si nécessaire la boutique en maintenance, conservez une copie des fichiers et des logs pour analyse, puis changez les mots de passe des accès à risque : hébergement, SFTP/SSH, base de données, back-office, e-mail et interfaces de paiement. Restaurez ensuite une sauvegarde antérieure vérifiée ou corrigez l’intrusion identifiée, mettez à jour les composants concernés et testez le parcours de commande avant la remise en ligne.
Documentez les accès, les versions, les modules critiques, l’emplacement des sauvegardes et les coordonnées des prestataires. Ce document réduit fortement le délai de rétablissement lorsqu’un incident survient, y compris lorsque la personne habituellement responsable est indisponible.
Faut-il changer le nom du dossier admin de PrestaShop ?
Oui, un nom de dossier d’administration non prévisible réduit les tentatives automatisées sur une URL connue, mais il ne remplace ni un mot de passe robuste ni le contrôle des accès. Conservez l’URL dans un gestionnaire de mots de passe et ajoutez, si possible, une restriction par VPN ou par adresse IP.
Une sauvegarde automatique suffit-elle pour protéger ma boutique ?
Non. Une sauvegarde n’est utile que si elle contient les fichiers et la base de données, qu’elle est conservée hors du serveur principal et qu’elle peut être restaurée. Testez régulièrement la restauration sur une préproduction, notamment après une évolution importante.
Quels fichiers PrestaShop faut-il sauvegarder en plus de la base de données ?
Sauvegardez toute l’arborescence de la boutique, en particulier les images produits, le thème, les modules, les fichiers de configuration, les éventuelles surcharges et les documents téléversés. La base seule ne permet pas de reconstruire les médias ni les personnalisations de fichiers.
Peut-on bloquer l’accès au back-office par adresse IP ?
Oui, cette restriction peut être configurée au niveau du serveur web, de l’hébergement ou d’un pare-feu. Elle convient surtout aux équipes utilisant des IP fixes ou un VPN. Testez l’accès depuis les lieux de travail autorisés et prévoyez un accès de secours administré.
Comment savoir si un module PrestaShop est encore nécessaire ?
Relevez les fonctionnalités réellement utilisées, les pages ou crochets sur lesquels le module intervient et ses éventuelles tâches planifiées. Testez sa désactivation sur une préproduction, puis vérifiez le front-office, le tunnel de commande et le back-office avant de le désinstaller en production.