Sécuriser votre boutique PrestaShop : guide pratique pour les propriétaires de boutiques

Gérer une boutique en ligne, c'est manipuler de l'argent réel et des données clients réelles. Ça fait de vous une cible — non pas parce que vous êtes particulièrement intéressant, mais parce que des bots automatisés scrutent en permanence chaque installation WordPress, Magento et PrestaShop sur Internet à la recherche de failles connues. La bonne nouvelle : la plupart des attaques réussissent à cause d'erreurs basiques, et les erreurs basiques se corrigent. Ce guide couvre ce qui compte vraiment, dans l'ordre où ça compte vraiment.

SSL : vous l'avez, mais est-il correctement configuré ?

Toutes les boutiques ont un certificat SSL aujourd'hui. La plupart l'ont mal configuré. Le cadenas dans votre navigateur signifie seulement que la page elle-même a été chargée en HTTPS — pas que votre boutique est entièrement chiffrée. Le problème caché, c'est le contenu mixte : des images, des scripts ou des feuilles de style qui se chargent en HTTP simple sur une page HTTPS. Les navigateurs les bloquent silencieusement, ce qui casse des fonctionnalités sans message d'erreur apparent.

Ouvrez Chrome DevTools sur votre page d'accueil, allez dans la Console et cherchez les avertissements « Mixed Content ». Corrigez-les en mettant à jour les URLs http:// codées en dur dans votre thème, vos modules ou les paramètres de la base de données. Dans PrestaShop, vérifiez dans Paramètres de la boutique → Général que le domaine de la boutique et le domaine SSL pointent tous les deux vers votre URL HTTPS.

Vérifiez aussi que la redirection HTTP vers HTTPS fonctionne au niveau serveur, pas seulement dans PrestaShop. Si quelqu'un visite http://yourstore.com, il doit recevoir une redirection 301 vers https://yourstore.com avant même que PrestaShop ne se charge. Contrôlez votre .htaccess — la règle de redirection doit précéder les règles de réécriture PrestaShop, pas être enfouie dedans.

Votre URL d'administration n'est pas un secret

Par défaut, PrestaShop place le panneau d'administration sous /admin suivi d'un suffixe aléatoire généré à l'installation. Ce suffixe n'est pas une mesure de sécurité — c'est juste une légère friction. Les bots testent les patterns courants. Votre URL d'admin est bien moins cachée que vous ne le pensez.

Renommez le répertoire admin avec quelque chose qui ne contient pas le mot « admin ». Choisissez quelque chose de sans signification — évitez complètement les mots du dictionnaire. Ça n'arrêtera pas un attaquant déterminé ayant accès à vos fichiers, mais ça élimine immédiatement le scanning automatisé massif.

Si votre hébergement supporte le filtrage par IP via .htaccess, utilisez-le. Ajoutez une directive Require ip dans le .htaccess de votre dossier admin pour n'autoriser que vos adresses IP bureau et domicile. Oui, c'est contraignant en déplacement. Oui, ça en vaut la peine.

Comptes employés : une personne, un compte, sans exception

Les comptes admin partagés sont l'une des causes les plus fréquentes d'incidents de sécurité — et les plus difficiles à analyser après coup. Quand tous les employés se connectent en tant qu'« admin », il n'y a aucune piste d'audit. Impossible de savoir qui a supprimé un produit, modifié un prix, ou exporté la liste clients à 2h du matin.

Créez des comptes individuels pour chaque personne ayant accès au back-office. Utilisez correctement les profils de permissions de PrestaShop : un agent du service client n'a pas besoin d'accéder aux paramètres de paiement. Un opérateur d'entrepôt n'a pas besoin d'accéder à la gestion des employés. Le principe du moindre privilège n'est pas de la bureaucratie — il limite les dégâts quand un compte est compromis.

Auditez votre liste d'employés chaque trimestre. Supprimez les comptes des personnes qui ne travaillent plus pour vous. D'anciens employés avec des identifiants actifs représentent un vrai vecteur de risque, et c'est l'un de ceux que vous contrôlez entièrement.

Sécurité des modules : la surface d'attaque que vous ne surveillez pas

Les modules sont le point d'entrée le plus courant pour les compromissions de boutiques PrestaShop. Un module vulnérable — même un que vous n'utilisez plus activement — peut être exploité s'il est installé et activé. Les attaquants se moquent de savoir que vous n'avez pas touché à ce module de paiement depuis deux ans. S'il est là et vulnérable, c'est une porte ouverte.

N'installez que des modules provenant de sources fiables. La marketplace PrestaShop Addons vérifie les soumissions — les sites tiers au hasard et les repos GitHub aléatoires, non. Les modules nulled — des modules payants distribués illégalement et gratuitement — contiennent presque toujours des backdoors. La logique est simple : pourquoi quelqu'un offrirait-il un logiciel payant gratuitement ? Parce qu'il y a ajouté quelque chose.

Supprimez les modules que vous n'utilisez pas. Pas seulement les désactiver — les désinstaller et supprimer les fichiers. Chaque module installé ajoute du code chargé à chaque requête, augmentant à la fois la surface d'attaque et le temps de chargement. Faites un audit des modules : si vous ne l'avez pas utilisé depuis six mois et ne prévoyez pas de le faire, il part.

Mettez vos modules à jour régulièrement. La plupart des failles de sécurité dans les modules sont corrigées rapidement une fois découvertes — mais le correctif n'aide que si vous l'installez. Notre module Security Revolution inclut une surveillance de l'intégrité des fichiers qui signale tout changement inattendu dans vos fichiers de modules, et notre module Total Defender ajoute des couches de protection active incluant le blocage de bots et la journalisation des activités suspectes.

Sauvegardes de base de données : la seule garantie de récupération

Les sauvegardes ne sont pas une mesure de sécurité — ce sont une mesure de récupération. La distinction est importante parce qu'elle change votre façon de les envisager. Aucune stratégie de sauvegarde ne prévient une attaque. De bonnes sauvegardes signifient qu'une attaque ne met pas fin à votre activité.

Automatisez vos sauvegardes. Les sauvegardes manuelles se font sauter, retarder et oublier. Configurez un cron job qui exporte votre base de données chaque nuit et la copie hors serveur. « Hors serveur » signifie quelque part où une compromission de votre serveur web ne compromet pas aussi vos sauvegardes — un bucket cloud séparé, votre machine locale, n'importe où qui n'est pas la même machine susceptible d'être effacée.

Testez vos restaurations. Une sauvegarde que vous n'avez jamais restaurée n'est pas une sauvegarde — c'est un fichier au contenu inconnu. Effectuez une restauration test sur un environnement de staging au moins une fois par trimestre. La première fois que vous restaurez depuis une sauvegarde ne doit pas être lors d'un incident réel.

Conservez plusieurs points de restauration. Des sauvegardes quotidiennes pour les 30 derniers jours, hebdomadaires pour les six derniers mois. Certaines attaques — notamment la manipulation de base de données — ne sont pas découvertes immédiatement. Vous devez pouvoir restaurer un état antérieur au début de la compromission.

Mots de passe et double authentification

PrestaShop supporte nativement la double authentification depuis la version 1.7.6. Si vous ne l'utilisez pas pour vos comptes admin, activez-la aujourd'hui. La configuration prend cinq minutes. Allez dans votre profil dans le back-office et activez la 2FA avec une application d'authentification comme Google Authenticator ou Authy.

Exigez la 2FA pour tous les comptes admin, pas seulement le vôtre. Un employé avec un mot de passe faible et sans 2FA est le maillon faible de votre chaîne de sécurité.

Concernant les mots de passe : utilisez un gestionnaire de mots de passe et générez des mots de passe longs et aléatoires pour chaque compte. « Long » signifie 20 caractères minimum pour les comptes admin. Ne réutilisez jamais un mot de passe d'un service à l'autre. Votre mot de passe admin PrestaShop ne doit apparaître nulle part ailleurs — ni dans votre panneau d'hébergement, ni dans votre messagerie, ni dans votre compte sur la marketplace de modules.

Permissions de fichiers : les bases restent essentielles

Les permissions correctes pour une installation PrestaShop sont 755 pour les répertoires et 644 pour les fichiers. Si vous ou votre hébergeur avez un jour mis des permissions à 777 « pour régler un problème », revenez-y et réglez-le correctement. Des fichiers accessibles en écriture par tous signifient que n'importe quel processus sur le serveur — y compris du code injecté via une vulnérabilité — peut les modifier.

Vérifiez spécifiquement les permissions de votre fichier config/settings.inc.php. Il contient vos identifiants de base de données. Il doit être en 444 ou 640 — lisible par le serveur web, non inscriptible par quiconque.

Sur un hébergement mutualisé, votre profil de risque est plus élevé car vous partagez un serveur avec d'autres sites. La compromission d'un autre site sur votre serveur peut potentiellement affecter le vôtre si les permissions sont trop ouvertes. C'est l'un des vrais arguments en faveur d'un VPS plutôt que d'un hébergement mutualisé pour les boutiques avec un vrai volume de transactions.

Garder PrestaShop et PHP à jour

Les vieilles versions de PHP ne sont pas seulement plus lentes — elles ne reçoivent plus de correctifs de sécurité. PHP 7.4 a atteint sa fin de vie en novembre 2022. Si votre hébergeur l'utilise encore (et beaucoup d'hébergeurs mutualisés le font), vous exploitez des vulnérabilités connues et non corrigées dans l'environnement d'exécution de votre serveur. Vérifiez votre version PHP dans le back-office PrestaShop sous Paramètres avancés → Informations.

PrestaShop publie des correctifs de sécurité dans les versions mineures. Tourner en 8.1.0 quand la 8.1.7 est disponible, c'est laisser des failles de sécurité connues ouvertes. Les mises à jour de version majeure demandent plus de précautions, mais les mises à jour mineures dans la même branche sont généralement sûres et doivent être appliquées rapidement après une sauvegarde et un test en staging.

Durcissement du .htaccess

Le .htaccess par défaut de PrestaShop est un point de départ, pas une configuration de sécurité finalisée. Ajoutez ces règles pour bloquer l'accès direct aux répertoires qui ne doivent jamais être publiquement accessibles :

• Bloquer l'accès direct à /config/ — contient les identifiants de base de données et les clés de chiffrement
• Bloquer l'accès direct à /var/ — contient les fichiers de cache et les logs
• Bloquer l'accès direct à /vendor/ — contient les fichiers de bibliothèques tierces
• Bloquer l'accès direct à /src/ — contient les fichiers source du cœur
• Bloquer l'exécution de fichiers PHP dans /upload/ — une cible courante pour les uploads de malware

Pour le répertoire d'upload spécifiquement, ajoutez un .htaccess dans /upload/ qui interdit l'exécution PHP. Si un attaquant télécharge un shell PHP via une vulnérabilité de téléchargement de fichiers, cette règle l'empêche de l'exécuter.

RGPD et sécurité des cookies

La sécurité des cookies n'est pas seulement une question de conformité — des cookies mal configurés peuvent exposer des tokens de session et des données d'authentification. Assurez-vous que vos cookies de session sont définis avec le flag Secure (transmis uniquement en HTTPS) et le flag HttpOnly (inaccessible au JavaScript). Si vous avez besoin d'une implémentation correcte du consentement aux cookies conforme au RGPD qui ne casse pas les fonctionnalités de votre boutique, notre module Cookies Revolution gère cela correctement.

En cas de piratage : ce qu'il faut vraiment faire

Premièrement : pas de panique, mais agissez vite. Chaque heure de délai représente plus de dommages potentiels.

Isolez immédiatement. Mettez votre boutique hors ligne ou en mode maintenance. Si votre hébergeur propose une option « suspendre le site », utilisez-la. Il faut arrêter l'hémorragie avant de diagnostiquer la blessure.

Ne supprimez rien pour l'instant. L'instinct sera de nettoyer, mais vous devez préserver les preuves pour comprendre ce qui s'est passé. Faites une sauvegarde complète de l'état compromis avant de commencer à supprimer des fichiers.

Vérifiez les dates de modification des fichiers. Lancez une recherche sur les fichiers modifiés au cours des 30 derniers jours. Comparez avec votre historique de déploiement. Les fichiers qui ont changé sans mise à jour correspondante sont des indicateurs de compromission. Portez une attention particulière aux fichiers PHP dans /upload/, /img/ et les répertoires de modules — des endroits où les écritures de fichiers sont attendues et plus faciles à dissimuler.

Restaurez depuis une sauvegarde propre. N'essayez pas de supprimer chirurgicalement les malwares d'un site actif — les attaquants sont doués pour cacher des backdoors et vous en raterez. Restaurez depuis une sauvegarde que vous êtes sûr d'être antérieure à la compromission.

Changez tous les mots de passe. Mot de passe de la base de données, identifiants FTP, panneau d'hébergement, comptes admin PrestaShop, comptes e-mail associés au domaine. Considérez que tout était lisible pendant la période de compromission.

Trouvez le point d'entrée. C'est essentiel pour éviter que ça se reproduise. Points d'entrée courants : un module vulnérable, des identifiants d'employé compromis, un mot de passe admin forcé par brute force. Si vous ne comprenez pas comment c'est arrivé, ça arrivera à nouveau.

Notifiez de manière appropriée. Si des données clients ont été accédées — adresses e-mail, historique des commandes, données de paiement — vous avez probablement des obligations légales de notification selon votre juridiction. Le RGPD exige une notification dans les 72 heures suivant la prise de connaissance d'une violation. Ne tardez pas.

La sécurité n'est pas une fonctionnalité qu'on ajoute une fois pour toutes et qu'on oublie. C'est de la maintenance, comme garder le contenu de votre boutique à jour ou votre inventaire exact. Programmez un rappel trimestriel pour auditer les comptes employés, vérifier les mises à jour de modules et vous assurer que vos sauvegardes se restaurent vraiment. Vingt minutes tous les trois mois, c'est bien moins cher que de gérer les conséquences d'une intrusion.

Articles Connexes

• Securite des paiements dans PrestaShop : PCI Compliance, 3D Secure et prevention de la fraude
• Securiser PrestaShop : La checklist complete de durcissement
• Réponse aux Violations de Données : Que Faire Si Votre Boutique Est Piratée