Les boutiques PrestaShop sont parmi les cibles les plus recherchées des groupes de cybercriminalité spécialisés dans le vol de données de paiement. Ce n’est pas une exagération : les attaques dites Magecart — injection de code malveillant pour intercepter les numéros de carte en temps réel — ont compromis des milliers de boutiques PrestaShop ces dernières années, dont une vague majeure exploitant la CVE-2022-36408 qui a touché plus de 4 400 boutiques en France.
La raison est simple : PrestaShop traite des données financières directes. Un accès au back-office ou au code source, et l’attaquant peut injecter un script discret qui collecte les données de carte de chaque acheteur — sans que vous vous en rendiez compte pendant des semaines.
Voici les 8 mesures indispensables pour protéger votre boutique en 2026.
Mesure 1 : supprimer le dossier /install
C’est l’oubli numéro un. Après l’installation de PrestaShop, le dossier /install doit être supprimé définitivement du serveur. PrestaShop vous l’indique d’ailleurs dans son assistant de post-installation — mais l’étape est oubliée dans environ 30 % des cas selon les analyses de sécurité publiées par des firmes spécialisées.
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/installVé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 : activer le token de sécurité
Dans votre back-office : Paramètres > Général > Augmenter la sécurité du front-office — activez l’option “Autoriser les tokens d’URL”.
Ce mécanisme ajoute un token unique à chaque URL du back-office. Sans ce token, les requêtes forgées (CSRF) vers votre administration sont rejetées. C’est une protection anti-CSRF native, à ne jamais désactiver.
Mesure 4 : désactiver l’affichage des erreurs en production
En mode développement, PrestaShop affiche les erreurs PHP et les stack traces 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);En PrestaShop 8.x, ce paramètre est également contrôlable via la variable d’environnement PS_DEV_MODE=0.
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 Boutique > Général — activez “SSL” et “Activer 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
La majorité des compromissions PrestaShop exploitent des vulnérabilités connues et corrigées dans des versions anciennes. 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 ou une faille XSS peut compromettre toute la boutique même si PrestaShop core est à jour.
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.
Les modules de monitoring d’intégrité comparent régulièrement les hash des fichiers critiques à une référence connue et vous alertent en cas de modification inattendue. Parmi les solutions utilisées sur des boutiques en production :
- Security Pro (Prestashop Addons) : audit d’intégrité + scan de malwares
- Watchdog : monitoring fichiers et alertes email
- Des solutions de monitoring serveur comme Wazuh (open source) si vous gérez votre propre infrastructure
Modules de sécurité complémentaires
En dehors du monitoring d’intégrité, d’autres fonctions méritent d’être couvertes :
- Protection anti-brute-force back-office : PrestaShop 8 intègre un mécanisme de blocage après N tentatives échouées, mais des modules tiers permettent d’affiner (délai, notification, whitelist IP)
- 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 bulletins de sécurité PrestaShop (build.prestashop-project.org)
PS 1.6 / 1.7 vs PS 8 : une surface d’attaque différente
PrestaShop 1.6 n’est plus maintenu depuis janvier 2019. PrestaShop 1.7 a atteint sa fin de vie en octobre 2023. Si votre boutique tourne encore sur l’une de ces versions, aucun correctif de sécurité ne sera publié pour les nouvelles vulnérabilités découvertes.
PS 8.x apporte des améliorations notables : meilleure gestion des tokens CSRF, support natif de la 2FA pour les comptes admin, architecture Symfony plus stricte sur les entrées utilisateur. La migration reste un chantier technique non trivial — mais continuer sur PS 1.7 en 2026, c’est gérer une boutique dont la surface d’attaque grandit chaque mois.
La sécurité PrestaShop n’est pas un projet ponctuel, c’est un processus continu. Si vous préférez déléguer cette surveillance à des experts, notre service de maintenance PrestaShop couvre l’ensemble de ces mesures — mises à jour, monitoring d’intégrité, audits de sécurité mensuels. En cas d’incident avéré, notre service d’urgence site PrestaShop permet une intervention rapide pour limiter la durée d’exposition.
