Sécuriser le back-office PrestaShop : accès, 2FA, journaux

Mis à jour le 1er novembre 2026. Article réécrit à partir du code de PrestaShop 9.2.0 : surfaces d’administration à protéger (dossier admin, API d’administration, webservice), configuration Nginx testée et piège de priorité des blocs location, réglages de Paramètres avancés > Sécurité, état de la double authentification, position de l’ANSSI sur le Zero Trust (juin 2025).

Protéger le back-office d’une boutique PrestaShop ne se résume pas à choisir entre un VPN et un accès Zero Trust (ZTNA). Il faut d’abord savoir quelles adresses donnent accès à l’administration, puis décider qui peut les atteindre, comment chacun s’authentifie et ce qui reste tracé. Cet article suit cet ordre, avec ce que PrestaShop 9.2 fournit réellement et ce qu’il faut ajouter.

Recenser les portes d’entrée

Dans PrestaShop 9, l’administration n’est pas limitée au dossier admin. Trois points d’entrée sont à traiter, plus les modules.

Le dossier /admin-api/ se trouve à la racine, à côté du dossier admin : renommer ce dernier ne le masque pas. Si un assistant d’IA est relié à la boutique, le serveur MCP ajoute une interface de plus ; voir notre guide PrestaShop et MCP.

Le dossier admin renommé : utile, insuffisant

L’installation de PrestaShop 9 donne au dossier d’administration un nom aléatoire, et le robots.txt généré ne le mentionne pas. Cela réduit le bruit des robots qui testent /admin/. Ce n’est pas une protection : le nom peut fuiter par un ancien lien, une capture d’écran, un fichier de sauvegarde ou des journaux exposés. Gardez-le, mais ne comptez pas dessus.

Le pare-feu Symfony du back-office de la version 9.2 ne configure aucune limitation des tentatives de connexion (login_throttling absent de app/config/admin/security.yml). Une page de connexion joignable depuis Internet peut donc être soumise à des essais de mots de passe sans frein applicatif. C’est l’argument principal pour filtrer l’accès en amont.

Restreindre l’accès au niveau du serveur

Une configuration Nginx testée

Si les administrateurs passent par des adresses fixes (bureau, sortie d’un VPN ou d’un connecteur ZTNA), une restriction par IP ferme la porte à tous les autres. Voici un extrait à intégrer dans le bloc server de la boutique, adapté de la configuration Nginx publiée dans la documentation PrestaShop 9 :

# Webservice : reecriture standard de PrestaShop
rewrite ^/api/?(.*)$ /webservice/dispatcher.php?url=$1 last;

# Back-office : dossier renomme, reserve a deux origines
location ^~ /admin-a1b2c3/ {
    allow 203.0.113.10;        # bureau
    allow 198.51.100.0/24;     # sortie du VPN ou du connecteur ZTNA
    deny all;
    try_files $uri $uri/ /admin-a1b2c3/index.php$is_args$args;
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        try_files $fastcgi_script_name =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $request_filename;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

# API d'administration (PrestaShop 9)
location ^~ /admin-api/ {
    allow 203.0.113.10;
    deny all;
    try_files $uri /admin-api/index.php$is_args$args;
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        try_files $fastcgi_script_name =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $request_filename;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

# Webservice : /api/ est reecrit vers ce dossier, c'est lui qu'il faut filtrer
location ^~ /webservice/ {
    allow 192.0.2.25;          # serveur qui consomme l'API
    deny all;
    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        try_files $fastcgi_script_name =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $request_filename;
        fastcgi_param PATH_INFO $fastcgi_path_info;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Remplacez admin-a1b2c3 par le nom de votre dossier, les adresses d’exemple par les vôtres et le socket PHP-FPM par celui de votre serveur. Nous avons vérifié cette configuration avec Nginx 1.28.2 (nginx -t), puis en la faisant tourner en local, interrogée depuis une adresse non autorisée : le dossier admin, index.php, les routes du type index.php/sell/catalog/products, /admin-api/, /api/products et /webservice/dispatcher.php renvoient tous 403.

Le piège de la priorité des blocs location

Dans la configuration de référence, le bloc du dossier admin est un simple préfixe (location /admin-dev/) et les fichiers PHP sont traités par un bloc d’expression régulière global. Si vous ajoutez allow et deny dans ce bloc préfixe sans y imbriquer le traitement PHP, Nginx choisit le bloc d’expression régulière pour toute URL qui contient .php. Notre test l’a confirmé : /admin-a1b2c3/ renvoyait 403, mais /admin-a1b2c3/index.php passait au gestionnaire PHP. D’où le modificateur ^~ et le bloc PHP imbriqué ci-dessus.

Après toute modification, testez depuis une connexion extérieure (réseau mobile, par exemple) :

for u in /admin-a1b2c3/ /admin-a1b2c3/index.php /admin-api/products /api/products /webservice/dispatcher.php; do
  echo "$u -> $(curl -s -o /dev/null -w '%{http_code}' "https://boutique.example.fr$u")"
done

Chaque ligne doit afficher 403.

VPN ou ZTNA : choisir selon le besoin

Les deux approches font arriver les administrateurs par un chemin contrôlé ; la restriction IP ci-dessus n’autorise alors que ce chemin.

Dans ses Fondamentaux sur le Zero Trust publiés le 20 juin 2025, l’ANSSI présente ce modèle comme une démarche progressive, à intégrer dans une défense en profondeur, complémentaire du filtrage périmétrique et non comme son remplaçant. Un ZTNA ne protège rien si l’adresse d’origine de la boutique reste joignable par un autre chemin : c’est le rôle de la restriction côté serveur.

Deux points pratiques. L’option « Vérifier l’adresse IP du cookie » (Paramètres avancés > Administration) déconnecte un employé dont l’adresse change en cours de session : avec un proxy dont les adresses de sortie varient, des déconnexions peuvent apparaître. Et un proxy ajoute un saut réseau à chaque requête du back-office : mesurez le temps de réponse avant et après.

Double authentification : ce que propose PrestaShop 9.2

Nous n’avons trouvé aucune double authentification des employés dans le cœur de PrestaShop 9.2.0 : ni code TOTP, ni second facteur dans le formulaire de connexion. Trois solutions existent :

1. Le second facteur du fournisseur ZTNA ou du VPN : l’identité est vérifiée avant même d’atteindre la page de connexion.
2. Un module tiers de double authentification pour le back-office : vérifiez sa compatibilité 9.x, la possibilité de l’imposer à tous les employés et la procédure de récupération en cas de perte du téléphone.
3. Une authentification HTTP en amont, en complément, pour les petites équipes sans fournisseur d’identité.

Le guide de l’ANSSI sur l’authentification multifacteur et les mots de passe (version 2.0, octobre 2021) déconseille notamment le SMS comme facteur et recommande un gestionnaire de mots de passe.

Les réglages natifs à appliquer

Dans Paramètres avancés > Sécurité (PrestaShop 9.2) :

• Protection des jetons dans le back-office : laissez-la activée ; elle impose un jeton dans les URL du back-office.
• Politique de mots de passe : longueur minimale, longueur maximale et score de sécurité minimum.
• Sessions employés et Sessions clients : listes des sessions ouvertes, avec suppression unitaire ou groupée. Supprimez les sessions d’un employé qui quitte l’équipe.

Dans Paramètres avancés > Administration : « Vérifier l’adresse IP du cookie » et « Durée de vie du cookie back-office », à réduire si les postes sont partagés.

Comptes employés et journaux

Créez des comptes nominatifs, jamais partagés, avec le profil le plus restreint possible (Paramètres avancés > Équipe : employés, profils, permissions). Un ancien compte d’agence resté actif annule l’effet d’une architecture soignée. Cette requête en lecture seule, testée sur une base 9.2 (préfixe ps_ à adapter), liste les comptes et leur dernière activité connue :

SELECT e.id_employee, e.active, pl.name AS profil, e.last_passwd_gen,
       MAX(s.date_upd) AS derniere_activite
FROM ps_employee e
LEFT JOIN ps_profile_lang pl ON pl.id_profile = e.id_profile AND pl.id_lang = 1
LEFT JOIN ps_employee_session s ON s.id_employee = e.id_employee
GROUP BY e.id_employee, e.active, pl.name, e.last_passwd_gen
ORDER BY derniere_activite;

Côté journaux, ne comptez pas sur le seul écran Paramètres avancés > Logs : nous n’avons pas trouvé dans le code 9.2 d’enregistrement des connexions réussies au back-office. Croisez trois sources : les journaux du serveur web (requêtes vers /login et vers le dossier admin), ceux du VPN ou du ZTNA, et les journaux de PrestaShop. La CNIL recommande de conserver les traces d’accès sur une durée glissante de six mois à un an, sauf justification. Notre guide d’analyse des logs Nginx donne les commandes utiles.

Mises à jour et compromission préexistante

Une politique d’accès ne corrige pas une faille : un module vulnérable reste exploitable par un utilisateur autorisé. Appliquez les mises à jour de PrestaShop, des modules, du système et de PHP, dont les correctifs du 21 octobre 2026, et supprimez les modules inutilisés. Les mesures côté serveur sont détaillées dans notre article sur la protection d’un serveur web.

Verrouiller l’accès ne supprime pas non plus ce qui a déjà été déposé : compte administrateur ajouté, module malveillant, tâche planifiée. Certains skimmers se désactivent quand un administrateur est connecté, et une réinfection après nettoyage peut venir de la base de données. En cas de doute, suivez la procédure de réinitialisation de l’accès admin après piratage et relisez l’historique de la faille blm.php.

Questions fréquentes

Faut-il abandonner le VPN au profit du ZTNA ?

Non. Un VPN segmenté, à jour et protégé par un second facteur reste pertinent pour l’administration système. Le ZTNA convient mieux quand le besoin se limite au back-office et que les intervenants changent souvent.

PrestaShop 9 propose-t-il une double authentification native ?

Pas dans la version 9.2.0 que nous avons examinée. Le second facteur vient d’un module tiers, du fournisseur d’identité du ZTNA ou du VPN.

Renommer le dossier admin suffit-il ?

Non. Le nom limite les tentatives automatiques sur /admin/, mais /admin-api/ et /api/ restent à la racine, et le nom peut fuiter. La protection vient du filtrage d’accès et de l’authentification.

Quel est le premier correctif à appliquer ?

Recensez les comptes employés, désactivez ceux qui ne servent plus, puis désactivez le webservice et l’API d’administration s’ils sont inutilisés. Ajoutez ensuite la restriction d’accès et le second facteur.

Sources

• Code de PrestaShop 9.2.0 (lecture locale) : app/config/admin/security.yml, src/PrestaShopBundle/Form/Admin/Configure/AdvancedParameters/Security/, src/PrestaShopBundle/EventListener/Admin/EmployeeSessionSubscriber.php, src/PrestaShopBundle/EventListener/API/AdminAPIFeatureListener.php, webservice/dispatcher.php, traductions fr-FR.
• PrestaShop Devdocs : configuration Nginx (9.x)
• PrestaShop Devdocs : Admin API
• ANSSI : Les fondamentaux, modèle Zero Trust (20 juin 2025)
• ANSSI : recommandations relatives à l’authentification multifacteur et aux mots de passe
• CNIL : recommandation relative aux mesures de journalisation (délibération n° 2021-122 du 14 octobre 2021)
• nginx.org : directive location

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →