Le back-office est la porte d'entrée la plus ciblée d'une boutique PrestaShop : c'est là que se trouvent les commandes, les clients et les moyens de paiement configurés. Voici les mesures concrètes pour rendre son accès nettement plus difficile à forcer.
Contrairement à une attaque visant le front (le site public), une intrusion réussie sur le back-office donne un accès direct aux données clients, à l'historique de commandes, aux paramètres de paiement et potentiellement à la possibilité d'injecter du code malveillant dans le thème ou les modules. C'est pourquoi son accès mérite un traitement à part, au-delà des mesures de sécurité générales du site.
Le dossier admin*** généré par défaut à l'installation doit être renommé en quelque chose de difficile à deviner (par exemple gestion-x8k2m9), en évitant des variantes trop évidentes comme « admin », « backoffice » ou « bo ».
Un module 2FA basé sur TOTP (Google Authenticator, Authy) doit être activé pour tous les comptes ayant accès au back-office, pas seulement le compte administrateur principal.
Pour une équipe travaillant depuis des adresses fixes (bureau, VPN d'entreprise), une whitelist d'IP configurée via .htaccess bloque tout accès venant d'ailleurs, avant même la page de connexion.
Limiter le nombre de tentatives de connexion via un module dédié, installer fail2ban pour bloquer automatiquement les IP suspectes, et déployer un WAF (Cloudflare, Sucuri, ModSecurity) en amont du serveur.
Mots de passe d'au moins 14 caractères, uniques par service, gérés via un gestionnaire de mots de passe dédié plutôt que mémorisés ou réutilisés d'un outil à l'autre.
Une boutique avec plusieurs collaborateurs accumule souvent des comptes back-office créés au fil du temps, avec des droits élargis « pour simplifier ». Chaque compte devrait au contraire disposer uniquement des permissions nécessaires à sa fonction : un préparateur de commandes n'a pas besoin d'accès aux paramètres de paiement, un community manager n'a pas besoin d'accès au catalogue produit complet.
| Situation à risque | Bonne pratique |
|---|---|
| Critique Comptes d'anciens employés actifs | Désactiver systématiquement l'accès dès le départ d'un collaborateur |
| Important Un seul compte « Super Admin » partagé | Un compte nominatif par personne, avec des droits adaptés à sa fonction |
| Important Pas de journal des connexions | Activer et consulter régulièrement les logs de connexion au back-office |
| Recommandé Modules installés « au cas où » | Désinstaller les modules et comptes inutilisés, chaque élément actif est une surface d'attaque |
Une bonne partie des mesures ci-dessus perd de son efficacité si le cœur de PrestaShop, le thème et les modules ne sont pas maintenus à jour. Une faille corrigée dans une nouvelle version reste exploitable indéfiniment sur une boutique qui n'applique pas le correctif.
Aucune protection n'est infaillible à 100%. Une politique de sauvegarde régulière et testée, avec un plan de reprise d'activité, reste le filet de sécurité indispensable en complément de ces mesures d'accès.