Pour sécuriser une boutique PrestaShop, l'essentiel tient en quelques mesures : une version maintenue avec des modules à jour (les modules tiers sont la porte d'entrée la plus fréquente), le dossier /install supprimé, un back-office à l'adresse imprévisible, le mode debug coupé, le HTTPS forcé, des accès FTP et SSH limités, et une surveillance des fichiers modifiés. Le détail de chaque mesure suit.
Les boutiques en ligne sont une cible de choix pour le vol de données de carte bancaire, avec des attaques dites Magecart ou « skimmers » : un script injecté dans la boutique intercepte les numéros de carte saisis par les clients. En juillet 2022, l'équipe PrestaShop a alerté sur une vague d'attaques exploitant des failles d'injection SQL, dans des versions anciennes ou des modules vulnérables, pour injecter du code et voler des données de paiement. La faille liée a été enregistrée sous la référence CVE-2022-36408.
Le problème, c'est la discrétion : un skimmer bien caché peut tourner des semaines avant qu'un client signale une fraude. Voici les mesures qui ferment les portes les plus utilisées.
Mesure 1 : supprimer le dossier /install
C'est un oubli classique, qu'on retrouve encore en audit. Après l'installation, le dossier /install doit être supprimé définitivement du serveur. PrestaShop le rappelle à la fin de l'installation, mais l'étape passe parfois à la trappe, notamment après une restauration ou un redéploiement.
Un dossier /install accessible permet à n'importe qui de relancer l'assistant d'installation et de réinitialiser votre boutique. En SSH ou via votre panel hébergeur :
rm -rf /var/www/html/install
Vérifiez ensuite que l'URL https://votreboutique.fr/install retourne bien une 404.
Mesure 2 : changer l'URL du back-office
Par défaut, PrestaShop crée un dossier admin renommé aléatoirement à l'installation (ex : admin4829xk). Si votre back-office est accessible via /admin ou un nom prévisible, vous facilitez les attaques par force brute.
Renommez ce dossier en quelque chose d'imprévisible (gestion2026, tableau-bord-ws…) et mettez à jour votre marque-page. Cette simple mesure élimine la grande majorité des tentatives automatisées.
Mesure 3 : garder les jetons de sécurité et renforcer les sessions
PrestaShop ajoute un jeton unique aux liens du back-office. C'est lui qui provoque parfois le message « Jeton de sécurité invalide » : une protection contre les requêtes forgées (CSRF), pas un bug. Ne la contournez pas, et suivez notre article sur l'erreur Invalid security token si elle vous gêne.
Dans Paramètres avancés > Administration, activez la vérification de l'adresse IP du cookie et réduisez la durée de vie des sessions du back-office : un cookie volé devient beaucoup moins utile. Dans Paramètres de la boutique > Général, l'option « Augmenter la sécurité du front-office » applique le même principe aux comptes clients.
Mesure 4 : désactiver l'affichage des erreurs en production
En mode développement, PrestaShop affiche les erreurs PHP et les traces d'exécution directement dans le navigateur. En production, c'est une fuite d'information : chemins absolus, noms de modules, versions de bibliothèques, autant d'indices pour un attaquant.
Vérifiez dans config/defines.inc.php ou via votre back-office (Paramètres avancés > Performance) que le mode debug est désactivé :
define('_PS_MODE_DEV_', false);
Mesure 5 : forcer HTTPS partout
En 2026, servir une boutique e-commerce en HTTP est inacceptable. Outre les avertissements navigateurs qui font fuir les acheteurs, une connexion non chiffrée expose les données de session et les formulaires à des attaques man-in-the-middle.
Dans le back-office : Paramètres de la boutique > Général, activez « Activer le SSL » puis « Activer le SSL sur toutes les pages ». Vérifiez ensuite que votre .htaccess redirige bien tout le trafic HTTP vers HTTPS :
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Mesure 6 : mises à jour régulières PrestaShop, thèmes et modules
Les compromissions PrestaShop que nous nettoyons exploitent presque toujours des vulnérabilités connues et déjà corrigées, dans une version ancienne ou un module pas à jour. Le problème : beaucoup de boutiques restent bloquées sur des versions obsolètes par crainte de casser des compatibilités.
La règle pratique :
- Correctifs de sécurité (ex : 8.1.6 → 8.1.7) : à appliquer dans les 72h après publication
- Mises à jour mineures : à planifier dans la semaine, sur un environnement de test d'abord
- Modules marketplace : vérifiez les mises à jour disponibles chaque mois
Les modules tiers sont souvent la porte d'entrée : un module peu maintenu avec une injection SQL peut compromettre toute la boutique, même si le cœur de PrestaShop est à jour. Pour savoir si l'un de vos modules a une faille connue, consultez les avis de sécurité de Friends of Presta, qui recensent les vulnérabilités des modules, et les avis officiels de PrestaShop pour le cœur. Avant chaque mise à jour, suivez notre méthode pour mettre à jour PrestaShop sans casse.
Mesure 7 : limiter les accès FTP et SSH
Chaque accès ouvert est une surface d'attaque potentielle. Auditez les comptes FTP/SSH actifs sur votre hébergement :
- Supprimez les accès inutilisés (ex : accès créé pour un prestataire qui n'intervient plus)
- Remplacez l'authentification par mot de passe SSH par des clés SSH : une clé Ed25519 est pratiquement impossible à forcer
- Limitez les IP autorisées si votre hébergeur le permet (liste blanche d'IP en FTP/SSH)
- Changez le port SSH par défaut (22) si vous gérez votre propre VPS
Si votre hébergeur mutualisé ne propose que du FTP, désactivez l'accès FTP en dehors des périodes de déploiement.
Mesure 8 : module de monitoring d'intégrité des fichiers
Le vecteur d'attaque Magecart le plus courant consiste à modifier un fichier PHP core ou un template pour y injecter du JavaScript malveillant. Sans monitoring, vous ne le détectez qu'en lisant les plaintes de clients dont les cartes ont été débitées frauduleusement.
Une surveillance d'intégrité compare régulièrement l'empreinte des fichiers critiques à une référence connue et vous alerte en cas de modification inattendue. Plusieurs approches existent :
- un module de sécurité de la marketplace PrestaShop Addons qui propose un scan d'intégrité, choisi chez un éditeur qui publie régulièrement des mises à jour ;
- un outil de surveillance serveur comme Wazuh (open source) si vous gérez votre propre serveur ;
- à défaut, une comparaison régulière avec une archive officielle de votre version de PrestaShop, qui repère les fichiers du cœur modifiés.
Modules de sécurité complémentaires
En dehors du monitoring d'intégrité, d'autres fonctions méritent d'être couvertes :
- Protection contre les attaques par force brute sur le back-office : limitation des tentatives de connexion, par un module ou au niveau du serveur, et liste d'adresses IP autorisées si votre équipe travaille depuis des lieux fixes
- Pare-feu applicatif (WAF) : Cloudflare (plan gratuit inclut des règles WAF basiques) ou des solutions comme BitNinja côté serveur
- Détection de skimmer côté client : des scripts de monitoring CSP (Content Security Policy) alertent si un script externe non autorisé tente de s'exécuter sur vos pages de paiement
Checklist mensuelle
Une fois par mois, passez en revue ces points :
- Vérifier les mises à jour disponibles PS + modules
- Consulter le journal d'activité admin (connexions inhabituelles ?)
- Vérifier que le dossier
/installn'existe pas (oui, certains re-déploiements le recréent) - Contrôler les comptes administrateurs actifs (supprimer ceux inutilisés)
- Vérifier la validité du certificat SSL (expiration)
- Tester une restauration de sauvegarde (voir article sur les sauvegardes PrestaShop automatiques)
- Consulter les avis de sécurité (PrestaShop sur GitHub, Friends of Presta pour les modules)
PS 1.6 / 1.7 vs PS 8 : une surface d'attaque différente
Les branches 1.6 et 1.7 ne sont plus maintenues, et elles ne tournent que sur des versions de PHP qui ne reçoivent plus de correctifs (7.4 au mieux, voir notre tableau de compatibilité PHP de PrestaShop). Chaque nouvelle faille découverte reste donc ouverte.
PrestaShop 8 et surtout 9 reposent davantage sur Symfony, plus strict sur le traitement des données saisies, et suivent des versions de PHP maintenues. La migration reste un vrai chantier, mais continuer sur une 1.6 ou une 1.7 en 2026, c'est gérer une boutique dont la surface d'attaque grandit chaque mois. Les risques sont détaillés dans les dangers d'un PrestaShop 1.6.
Les signes qu'une boutique PrestaShop est piratée
Réagissez immédiatement si vous constatez l'un de ces signes : des clients signalent des fraudes à la carte après un achat chez vous, une page ou une fenêtre de paiement inhabituelle apparaît avant le vrai paiement, un module de paiement inconnu figure dans la liste des modules, des comptes employés ont été créés sans vous, ou des fichiers JavaScript récents apparaissent dans le thème. Les premiers gestes sont décrits dans PrestaShop piraté : que faire.
La sécurité d'une boutique n'est pas un projet ponctuel, c'est un suivi. Pour savoir où en est la vôtre, un audit de sécurité PrestaShop vérifie la version, les modules et leurs failles connues, et les réglages ci-dessus. Pour déléguer le suivi, la maintenance PrestaShop couvre les mises à jour testées et la surveillance. En cas de piratage avéré, notre nettoyage de boutique PrestaShop piratée intervient rapidement pour limiter l'exposition de vos clients.
Pour approfondir : règlement européen sur la protection des données.
| Plateforme | Maintenance requise | Coût annuel type |
|---|---|---|
| Shopify | Abonnement + apps | 360-3 600 € |
| WooCommerce | Hébergement + extensions | 200-2 000 € |
| PrestaShop | Hébergement + modules + MAJ | 500-3 000 € |
Pour approfondir : Commission européenne – économie numérique.
