Double authentification, politiques de mots de passe et sécurité admin pour PrestaShop

Votre back-office PrestaShop est la porte de votre boutique qui ouvre sur tout : fiches clients, historique des commandes, configuration des paiements, gestionnaire de modules capable d'exécuter du PHP arbitraire, et un bouton d'export de base de données à deux clics. Pour la plupart des attaquants, il est beaucoup plus efficace d'entrer par cette porte avec des identifiants volés que de chercher une faille dans le code — et dans un grand nombre de boutiques, cette porte n'est protégée que par un seul mot de passe, que le propriétaire utilise aussi pour sa messagerie et pour un compte de forum compromis il y a trois ans. Cet article explique comment renforcer cette connexion unique : le second facteur, les règles de mots de passe, les comptes employés qui y ont accès, et la session qui reste ouverte quand vous vous éloignez de l'écran. C'est la couche de sécurité liée au contrôle d'accès. Les autres couches — permissions de fichiers, en-têtes, mises à jour, filtrage des bots — sont détaillées dans la checklist complète de renforcement de la sécurité, et la vue d'ensemble plus simple, non technique, se trouve dans le guide en langage clair pour les propriétaires de boutique.

Révisé en juin 2026 au regard du comportement du back-office de PrestaShop 1.6, 1.7, 8 et 9, ainsi que des recommandations NIST actuelles sur les mots de passe.

Où les connexions admin fuient réellement

Avant de chercher des outils, il est utile de nommer les défaillances précises, car chacune appelle une correction différente et propre à PrestaShop :

• Réutilisation des identifiants. La compromission la plus fréquente n'a rien à voir avec le code de PrestaShop. Un mot de passe administrateur divulgué par un service sans rapport est essayé sur votre page AdminLogin par un outil automatisé. Le mot de passe n'a jamais été « cassé » — il a été retrouvé dans une fuite.
• Comptes partagés. Un seul identifiant admin@ utilisé par trois personnes signifie que le journal d'activité attribue chaque modification à la même ligne, et que vous ne pouvez pas révoquer l'accès d'une personne sans bloquer les autres.
• Personnel avec trop de permissions. Un préparateur de commandes avec des droits SuperAdmin devient une faille de taille SuperAdmin si son ordinateur portable est piégé par phishing — il n'avait aucune raison d'accéder au gestionnaire de modules.
• Absence de second facteur. Un mot de passe seul est un point de défaillance unique. Du phishing, un keylogger ou un identifiant réutilisé suffit.
• Sessions qui ne se terminent jamais. Un back-office laissé ouvert sur une machine partagée ou volée est une session authentifiée que n'importe qui peut utiliser.

Chaque point ci-dessous associe une correction à l'une de ces situations. Rien n'exige de toucher aux fichiers du cœur.

Double authentification sur le back-office PrestaShop

La double authentification sépare la connexion entre ce que vous savez (le mot de passe) et ce que vous possédez (un code généré par votre téléphone). Si l'un est volé, l'autre reste nécessaire. Dans PrestaShop, la voie habituelle pour ajouter la 2FA au back-office passe par un module de sécurité fiable ou par une couche externe de contrôle d'accès placée devant la connexion — la première décision consiste donc à choisir comment l'ajouter, pas seulement où cliquer.

Comment la 2FA du back-office est réellement ajoutée

Ne partez pas du principe que le cœur fournit un interrupteur de double authentification prêt à l'emploi pour votre version. En général, PrestaShop 1.6, 1.7 et 8 ont besoin d'un module tiers fiable ou d'une couche externe de contrôle d'accès pour ajouter un second facteur au back-office. Ne considérez la 2FA comme « native » que si vous l'avez vérifiée pour votre version cible exacte dans la documentation officielle de cette version — une fonctionnalité présente dans une version mineure ne prouve pas qu'elle existe dans celle que vous utilisez.

Les options pratiques, par ordre approximatif d'effort :

• Un module de sécurité admin fiable qui ajoute le TOTP (le code rotatif à six chiffres généré par une application d'authentification comme Google Authenticator, Authy, Microsoft Authenticator, 1Password ou KeePass avec une extension TOTP). C'est la voie la plus courante et la seule qui fournisse un véritable second facteur par employé, basé sur une application.
• Une couche externe de contrôle d'accès — un proxy SSO/d'identité ou un WAF/reverse-proxy qui demande un second facteur avant même que la requête n'atteigne PrestaShop. Cela protège la surface de connexion sans toucher au cœur.
• Une liste d'IP autorisées (ci-dessous) comme mesure compensatoire lorsque vous ne pouvez déployer aucune des deux solutions précédentes — ce n'est pas un vrai second facteur, mais cela réduit fortement la surface d'attaque.

Activation

Quelle que soit la voie choisie, les étapes de configuration se trouvent dans le module ou le proxy que vous utilisez, pas dans un écran fixe du cœur — suivez donc les instructions propres à l'outil déployé. Pour un facteur basé sur une application d'authentification (TOTP), le déroulé ressemble généralement à ceci :

• Activez le second facteur pour votre propre compte dans les réglages du module ou du proxy.
• Scannez le QR code avec votre application d'authentification, puis saisissez le code actuel pour prouver que l'horloge est synchronisée. Un outil bien conçu ne finalise pas le réglage tant que vous n'avez pas confirmé ce code, afin d'éviter de vous enfermer dehors à cause d'un secret mal scanné.
• Enregistrez, puis testez : déconnectez-vous et reconnectez-vous. Le code rotatif doit vous être demandé après le mot de passe.

Deux notes opérationnelles évitent de vrais problèmes. D'abord, le TOTP dépend d'un accord entre l'horloge du téléphone et celle du serveur dans une petite fenêtre de temps ; si les codes sont refusés, vérifiez que l'heure de votre serveur est correcte (NTP) avant de conclure que la fonctionnalité est cassée. Ensuite, si votre module ou proxy 2FA fournit des codes de récupération ou de secours, conservez-les ailleurs que sur le téléphone — dans une entrée de gestionnaire de mots de passe, pas sur un post-it. S'il n'en fournit pas, documentez à l'avance sa propre procédure de récupération, car un téléphone perdu ou réinitialisé sans solution de secours peut nécessiter une intervention au niveau de la base de données (suppression des colonnes 2FA concernées, souvent sur votre ligne ps_employee) pour récupérer l'accès.

Rendez-la obligatoire, pas facultative

Un seul employé sans 2FA est le maillon faible dont dépend toute la chaîne : un attaquant qui entre dans n'importe quel compte dispose déjà d'un point d'appui pour aller plus loin. L'outil utilisé active généralement le second facteur personne par personne plutôt que de l'imposer à tout le compte, donc le caractère « obligatoire » est une règle que vous appliquez en vérifiant que chaque employé actif l'a activé. Si plusieurs employés travaillent dans la boutique et que vous voulez une inscription forcée (les nouveaux membres ne peuvent rien faire tant qu'ils ne l'ont pas configurée), cherchez un module ou une couche de contrôle d'accès qui prend en charge l'inscription imposée. Sur PrestaShop 1.6 et les premières versions 1.7 en particulier, un module ou une couche externe est la solution, sauf à verrouiller l'accès par IP.

Une politique de mots de passe conforme aux recommandations actuelles

L'objectif n'est pas d'avoir des mots de passe « complexes », mais des mots de passe impossibles à deviner, non réutilisés et résistants aux tentatives en masse. Les recommandations modernes (NIST et autres) ont abandonné l'ancien théâtre de la complexité et de la rotation au profit de la longueur et de l'unicité.

La consigne pratique pour l'équipe est courte : chaque compte back-office utilise un mot de passe unique, généré aléatoirement et stocké dans un gestionnaire (Bitwarden, 1Password, KeePass). Une chaîne aléatoire de 20 caractères est à la fois plus solide et plus facile à vivre qu'un mot de passe « malin » et mémorisable, car personne n'a besoin de le taper ni de s'en souvenir. La manière dont PrestaShop stocke ce mot de passe dépend de votre version : les versions modernes utilisent un algorithme de hachage robuste (le hachage avec facteur de coût derrière PrestaShop\PrestaShop\Core\Crypto\Hashing), de sorte qu'une fuite de base de données ne livre pas le texte en clair — mais l'ancien PrestaShop 1.6 utilisait un schéma plus faible basé sur la clé de cookie. Si vous êtes encore sur 1.6, considérez ses hachages stockés comme une protection limitée : prévoyez une mise à niveau ou une migration afin que les mots de passe soient rehachés avec l'algorithme moderne, et en attendant, appuyez-vous fortement sur des mots de passe uniques et robustes. Dans tous les cas, le hachage ne vaut rien si le mot de passe était admin123 et figure dans une liste publique.

Un contrôle propre à PrestaShop mérite d'être connu : le flux de réinitialisation du mot de passe est limité par la valeur de configuration PS_PASSWD_TIME_BACK (minutes entre deux demandes de réinitialisation back-office), ce qui empêche un attaquant de spammer les e-mails de réinitialisation. Vous avez rarement besoin d'y toucher, mais il existe.

Comptes employés : une personne, un identifiant, le moindre privilège

C'est la faille qui affaiblit silencieusement tous les autres contrôles. Le modèle de permissions de PrestaShop est réellement capable — le problème est presque toujours qu'il est laissé grand ouvert.

Un compte par personne

Chaque personne reçoit sa propre fiche employé dans Paramètres avancés → Équipe → Employés. Cela vous apporte trois choses à la fois : une piste d'audit qui indique qui a fait quoi (PrestaShop journalise les actions au nom de l'employé actif), la possibilité de désactiver un départ sans changer le mot de passe de tout le monde, et une 2FA par personne. Les identifiants partagés font perdre les trois.

Profils et principe du moindre privilège

Dans PrestaShop, les permissions ne sont pas définies par employé — elles sont définies sur un Profil (dans Paramètres avancés → Équipe → Permissions), et chaque employé est rattaché à un profil. Créez des profils qui correspondent aux rôles réels, puis la grille Voir / Ajouter / Modifier / Supprimer fait le reste :

Les deux règles importantes : limitez le profil SuperAdmin au propriétaire et, au maximum, à un responsable technique de confiance ; et souvenez-vous que la permission Modules équivaut en pratique à un droit d'exécution de code — toute personne capable d'installer un module peut exécuter du PHP sur votre serveur, donc traitez-la comme la permission critique qu'elle est, pas comme une commodité à distribuer.

Verrouiller la surface de connexion elle-même

Les deux facteurs protègent les identifiants ; ces mesures protègent la porte qu'ils ouvrent.

Gardez un nom de dossier admin aléatoire

PrestaShop installe le back-office dans un répertoire aléatoire (quelque chose comme /admin47ab9c/) précisément pour que les bots ne puissent pas le trouver en devinant /admin ou /backoffice. Gardez-le aléatoire. Si le vôtre a été renommé avec un nom prévisible pendant une migration, renommez le dossier sur le disque et PrestaShop reprendra automatiquement le nouveau chemin — l'obscurité n'est pas une mesure de sécurité à elle seule, mais elle vous retire du flot continu de scans automatisés qui martèlent les chemins évidents.

Limitez et surveillez les échecs de connexion

Les outils de brute force et de bourrage d'identifiants dépendent de leur capacité à tester rapidement des milliers de combinaisons. Deux défenses s'appliquent : côté application, ajoutez une vérification sur le formulaire de connexion pour bloquer les outils automatisés — c'est couvert dans reCAPTCHA pour PrestaShop. Côté réseau, limitez les personnes qui peuvent seulement atteindre la connexion. Si votre équipe se connecte depuis une IP de bureau fixe ou un VPN, une liste d'autorisation .htaccess ou pare-feu sur le répertoire admin bloque d'emblée toutes les autres sources, mot de passe valide ou non — cette règle et les autres mesures côté serveur sont détaillées dans les règles .htaccess de sécurité et de performance pour PrestaShop. Dans tous les cas, examinez les schémas d'échecs de connexion : une rafale d'échecs depuis une IP contre un employé précis est une attaque en cours.

# Apache 2.4, inside the randomized back-office directory
Require ip 203.0.113.10
Require ip 198.51.100.0/24

L'écran des tentatives bloquées de Total Defender liste les entrées par type, motif, adresse IP et date, et signale aucune tentative bloquée au cours des dernières 24 heures.

Sécurité des sessions : la partie que tout le monde oublie

Vous pouvez faire tout ce qui précède et tout de même offrir une session authentifiée à un attaquant si le back-office reste ouvert et connecté sur une machine sans surveillance. Trois contrôles referment cette brèche :

• Délai d'inactivité. PrestaShop fait expirer les sessions back-office en fonction du réglage PS_COOKIE_LIFETIME_BO (la durée de vie du cookie admin). Gardez-le assez court pour qu'un écran laissé sans surveillance se déconnecte tout seul — court pour les postes partagés, plus long uniquement lorsque la machine est réellement privée.
• Administration uniquement en HTTPS. Le back-office doit être accessible en HTTPS afin que le cookie de session ne puisse pas être intercepté sur un réseau de café ou d'hôtel. Si votre boutique n'est pas encore entièrement en HTTPS, corrigez cela d'abord — la marche à suivre est dans la configuration de SSL et HTTPS sur PrestaShop.
• Cookies Secure et HttpOnly. Une fois le site entièrement en HTTPS, le cookie de session admin doit porter les attributs Secure et HttpOnly afin de ne jamais être envoyé en clair et de ne pas pouvoir être lu par JavaScript — un cookie volé contourne la 2FA, ce n'est donc pas facultatif.

Vous pouvez vérifier la durée de vie actuelle du cookie back-office directement depuis la base de données ; la valeur est stockée en jours :

SELECT name, value
FROM ps_configuration
WHERE name IN ('PS_COOKIE_LIFETIME_BO', 'PS_PASSWD_TIME_BACK');

Surveillez le back-office, pas seulement le front-office

PrestaShop journalise certains événements et erreurs du back-office, et ce journal est un signal d'alerte précoce utile — mais considérez-le comme un enregistrement partiel, pas comme une piste d'audit complète ni comme un SIEM. Le journal intégré fera remonter des éléments comme un nouveau compte employé que vous n'avez pas créé, un changement soudain de permissions ou une modification inattendue de la configuration des paiements. À lui seul, il ne fournit pas un suivi fiable des connexions par IP ni une surveillance tenant compte du pays : détecter « une connexion à 04:00 depuis un pays où vous n'opérez pas » suppose généralement de corréler les journaux d'accès serveur, un module de sécurité dédié ou les logs de votre WAF/reverse-proxy, là où l'IP source est enregistrée. Prenez l'habitude de parcourir le journal intégré — au minimum chaque mois, chaque semaine si votre équipe change souvent — et associez-le au journal côté serveur qui indique la source d'authentification. Si vous soupçonnez déjà d'avoir dépassé le stade de l'alerte pour entrer dans une compromission active, arrêtez de lire des conseils de durcissement et suivez le plan d'incident dans réponse à une fuite de données : que faire si votre boutique est piratée.

Si vous ne pouvez pas déployer de module de 2FA

Beaucoup de boutiques sont bloquées sur une configuration figée — une ancienne version maintenue en place par un thème historique, un module ancien ou une version de PHP qu'une mise à niveau casserait — où l'ajout d'un module de sécurité est délicat. Vous avez encore des options : un module fiable peut ajouter le second facteur quand il s'intègre correctement, une couche externe de contrôle d'accès peut se placer devant la connexion, une liste d'IP autorisées peut isoler le back-office, et le reste des conseils de contrôle d'accès ici reste valable sans changement. La stratégie plus large pour renforcer une boutique que vous ne pouvez réellement pas encore faire évoluer — correctifs virtuels et mesures compensatoires — fait l'objet d'un article à part dans durcissement avancé de PrestaShop pour les boutiques que vous ne pouvez pas encore mettre à niveau.

Un verrouillage admin en 10 minutes, dans l'ordre

• Activez la 2FA sur votre propre compte SuperAdmin dès maintenant via votre module de sécurité ou votre couche de contrôle d'accès, et confirmez qu'une option de récupération est enregistrée hors appareil.
• Listez tous les employés actifs. Désactivez les identifiants partagés ; donnez à chaque personne son propre compte.
• Ouvrez Permissions et rétrogradez toute personne qui n'a pas besoin du statut SuperAdmin. Vérifiez que seules 1 à 2 personnes le détiennent, et que l'accès aux Modules est strictement limité.
• Accompagnez chaque personne restante dans l'activation de sa propre 2FA.
• Confirmez que chaque mot de passe admin est unique et généré par un gestionnaire — changez ceux qui ne le sont pas.
• Vérifiez que le nom du dossier admin est toujours aléatoire, et non /admin.
• Réduisez la durée de vie du cookie back-office afin que les sessions inactives soient déconnectées.
• Confirmez que l'administration est uniquement en HTTPS et que le cookie de session est Secure + HttpOnly.
• Lisez un mois de journaux admin. Notez à quoi ressemble la « normale » afin que l'anormal ressorte la prochaine fois.

Questions fréquentes

PrestaShop dispose-t-il d'une double authentification intégrée pour le back-office ?

Ne le supposez pas pour votre version. PrestaShop 1.6, 1.7 et 8 ont généralement besoin d'un module de sécurité admin fiable ou d'une couche externe de contrôle d'accès (un proxy SSO/d'identité, ou un WAF devant la connexion) pour ajouter un second facteur au back-office. Ne considérez la 2FA comme native que si vous l'avez vérifiée dans la documentation officielle de votre version exacte — une fonctionnalité présente dans une version mineure ne prouve pas qu'elle existe dans celle que vous utilisez.

Que se passe-t-il si je perds le téléphone avec mon application d'authentification ?

Si votre outil 2FA propose des codes de récupération ou de secours, vous les conservez hors du téléphone (dans une entrée de gestionnaire de mots de passe) et vous en utilisez un pour revenir dans le back-office. S'il n'en propose pas, vous utilisez sa procédure de récupération documentée, ce qui, dans de nombreuses configurations, signifie une intervention au niveau de la base de données — suppression des colonnes 2FA concernées sur votre ligne ps_employee afin de désactiver le second facteur pour ce compte, puis reconnexion et réinscription. C'est pour cela que le chemin de récupération se prépare avant d'activer la 2FA, pas après.

Dois-je forcer l'expiration de mes mots de passe admin tous les 90 jours ?

Non. Les recommandations actuelles (NIST et autres) ont abandonné la rotation planifiée, car elle pousse les gens de Summer2024! → Summer2025!, ce qui est plus faible, pas plus fort. Changez un mot de passe uniquement en cas de compromission suspectée. Concentrez plutôt l'effort sur la longueur et l'unicité : une chaîne de 16 caractères ou plus, générée aléatoirement, jamais réutilisée, issue d'un gestionnaire de mots de passe, une par compte.

Renommer le dossier admin en vaut-il vraiment la peine ?

Cela vaut la peine de le garder aléatoire, pas d'en faire une obsession. PrestaShop installe déjà le back-office dans un répertoire aléatoire afin que les bots ne puissent pas le trouver en devinant /admin ou /backoffice ; si une migration a laissé le vôtre prévisible, renommez le dossier sur le disque et PrestaShop reprendra le nouveau chemin. C'est de l'obscurité, pas une mesure de sécurité — cela vous retire du flot continu de scans automatisés, mais cela n'a de valeur qu'avec la 2FA, des mots de passe solides et une limitation des tentatives de connexion.

Comment arrêter les attaques par brute force et bourrage d'identifiants sur la connexion ?

Agissez sur deux niveaux de défense. Côté application, ajoutez une vérification sur le formulaire de connexion (reCAPTCHA) pour bloquer les outils automatisés. Côté réseau, limitez ceux qui peuvent atteindre la connexion — si votre équipe se connecte depuis une IP de bureau fixe ou un VPN, une liste d'autorisation .htaccess ou pare-feu sur le répertoire admin renvoie toutes les autres sources, mot de passe valide ou non. Aucun de ces contrôles ne remplace la 2FA, qui est ce qui vous protège lorsqu'un vrai mot de passe fuit.

Qu'est-ce que cela vous apporte concrètement ?

Appliquez cette liste et l'équation économique d'une attaque contre votre boutique change. Le bourrage d'identifiants échoue au second facteur. Un mot de passe obtenu par phishing ne sert à rien sans le téléphone. Un compte de préparateur de commandes compromis ne peut pas atteindre le gestionnaire de modules. Un ordinateur portable laissé ouvert se déconnecte tout seul. Rien de tout cela n'exige un développeur, une modification du cœur ou une mise à niveau que vous ne pouvez pas vous permettre — c'est de la configuration back-office et un gestionnaire de mots de passe. Nous développons des modules de sécurité et exploitons nous-mêmes des boutiques, donc le cadrage honnête est le suivant : le back-office est l'endroit où une intrusion passe de gênante à catastrophique, et le contrôle d'accès est l'heure la moins coûteuse et la plus rentable que vous y consacrerez. Quand vous serez prêt à renforcer les couches situées sous la connexion — fichiers, en-têtes, correctifs, trafic des bots — la checklist complète de durcissement sert de carte pour la suite.