Protéger un dossier d'administration sans dépendre du serveur web

La méthode classique pour verrouiller un espace d'administration consiste à demander au serveur web d'exiger un mot de passe avant même que la moindre ligne de code du site ne s'exécute. Cette protection est efficace, elle ne coûte presque rien, et elle pose trois problèmes récurrents : elle n'est pas disponible sur tous les hébergements, elle casse les appels asynchrones que le site public adresse à ce même dossier, et elle est ignorée par la plupart des équipes qui n'ont pas accès à la configuration du serveur. Nous présentons ici les alternatives applicatives, leurs forces et leurs limites respectives, et la façon de les combiner pour obtenir une protection comparable sans les effets de bord.

Pourquoi chercher une alternative

La protection par le serveur reste la référence et il existe plusieurs situations où elle ne convient pas ou ne suffit pas.

Les hébergements sans accès à la configuration

Beaucoup d'offres mutualisées ne permettent pas de créer les fichiers nécessaires, ou proposent une interface limitée qui ne couvre pas le cas voulu. Sur un hébergement en conteneur ou derrière un service de diffusion, la configuration du serveur est parfois entièrement gérée par le fournisseur. La protection doit alors se faire dans le code applicatif, seule couche que l'on maîtrise. Cette contrainte est de plus en plus fréquente avec les hébergements modernes. Elle n'implique aucune perte de sécurité si les alternatives sont correctement mises en place. Elle demande simplement une approche différente.

Les appels asynchrones cassés

Le site public adresse régulièrement des requêtes au dossier d'administration, notamment pour les formulaires, les filtres et les paniers. Protéger le dossier entier bloque ces requêtes et casse des fonctions visibles par les visiteurs. Les contournements possibles, consistant à exclure certains fichiers de la protection, sont détaillés dans notre article sur la manière de verrouiller l'accès à wp-admin par IP sans casser l'AJAX du front. Ces exclusions ouvrent une brèche partielle et elles restent le meilleur compromis dans beaucoup de cas. Une protection applicative évite ce compromis en distinguant les requêtes selon leur nature. C'est son principal avantage.

Les adresses réseau qui changent

Restreindre l'accès à une liste d'adresses fonctionne bien pour une équipe travaillant depuis un bureau à adresse fixe. Elle devient impraticable dès que les personnes travaillent depuis chez elles, en déplacement ou depuis une connexion mobile. Les demandes de déblocage se multiplient et l'administrateur finit par élargir la liste jusqu'à ce qu'elle ne protège plus rien. Cette dérive est prévisible et elle se produit systématiquement. Une protection fondée sur l'identité plutôt que sur l'emplacement supprime le problème. Elle demande un peu plus de travail initial et elle tient dans la durée.

L'expérience utilisateur dégradée

La fenêtre de saisie affichée par le navigateur est brutale, non traduite et non personnalisable. Les utilisateurs la confondent régulièrement avec un dysfonctionnement, et le double mot de passe qui suit déroute. Sur un site où des contributeurs externes doivent se connecter, cette friction génère des sollicitations au support. Une protection intégrée au site, avec un message clair, se comprend immédiatement. Cette différence d'ergonomie n'est pas anecdotique sur un espace utilisé quotidiennement. Elle pèse dans le choix autant que les considérations techniques.

L'absence de traçabilité

La protection par le serveur n'enregistre pas grand chose dans les journaux applicatifs, ce qui rend difficile le suivi des tentatives. Savoir qui a essayé de se connecter, quand et depuis où constitue pourtant une information utile en cas d'incident. Une protection applicative journalise naturellement ces événements avec le niveau de détail souhaité. Elle permet également de déclencher des alertes sur des comportements anormaux. Cette visibilité change la capacité à réagir. Elle constitue souvent la raison principale de préférer une solution applicative.

La nécessité de plusieurs niveaux

Aucune protection unique ne suffit, et la bonne pratique consiste à en superposer plusieurs de natures différentes. Un mot de passe fort, une limitation des tentatives, un second facteur et une adresse de connexion non devinable forment un ensemble bien plus solide qu'une seule mesure très stricte. Cette approche par couches tolère la défaillance de l'une d'elles. Elle correspond aussi mieux à la variété des scénarios d'attaque. Raisonner en couches plutôt qu'en solution unique est le bon réflexe. Il structure toute la démarche présentée ici.

Les protections applicatives disponibles

Plusieurs mécanismes se déclarent dans le code du site et s'appliquent avant toute action sensible.

Le contrôle en début de traitement

Le principe consiste à vérifier, au tout début du traitement de chaque requête vers l'espace protégé, que l'utilisateur est authentifié et dispose des droits nécessaires. Cette vérification s'inscrit dans un point d'entrée unique, ce qui évite de la répéter et d'en oublier. Elle se place avant toute lecture de base ou traitement coûteux, pour ne pas consommer de ressources sur une requête qui sera refusée. Ce que doit contenir un tel mécanisme, et ce qu'il vaut mieux ne pas coder soi même, est détaillé dans notre article sur le système d'authentification maison et ce qu'il faut vraiment coder. La rigueur du point d'entrée unique constitue le cœur du dispositif. Une seule page oubliée annule toute la protection.

La limitation des tentatives

Compter les échecs de connexion par identifiant et par adresse réseau, puis bloquer temporairement au delà d'un seuil, arrête les attaques par essais successifs. Le blocage doit être progressif, quelques secondes puis quelques minutes, plutôt que définitif. Un blocage définitif permettrait à un attaquant de verrouiller les comptes légitimes en les ciblant volontairement. Le compteur doit être stocké côté serveur, dans un cache ou en base, et non dans un cookie. Cette mesure est simple à implémenter et elle élimine la grande majorité du bruit automatisé. Elle constitue le meilleur rapport entre effort et bénéfice.

Le second facteur

Exiger un code temporaire en plus du mot de passe rend inutile le vol d'identifiants, qui reste le vecteur d'attaque le plus courant. Les applications générant ces codes sont gratuites et le mécanisme est standardisé, ce qui permet de l'implémenter sans dépendre d'un service tiers. Son fonctionnement et ses modalités sont présentés dans notre article sur la double authentification et ses principes. La mise en place demande de prévoir la procédure de récupération en cas de perte de l'appareil, point souvent négligé. Des codes de secours, générés à l'activation et conservés hors ligne, remplissent ce rôle. Sans cette procédure, un utilisateur perd définitivement l'accès à son compte.

L'adresse de connexion modifiée

Déplacer la page de connexion vers une adresse non standard supprime l'essentiel du trafic automatisé, qui cible toujours les emplacements par défaut. Cette mesure ne protège pas contre une attaque ciblée et elle réduit considérablement la charge et le bruit dans les journaux. Elle doit s'accompagner du blocage de l'ancienne adresse, faute de quoi elle ne sert à rien. Il faut également penser aux applications mobiles et aux outils externes qui utilisent l'adresse standard. Cette mesure relève de l'hygiène plutôt que de la sécurité au sens strict. Elle reste largement utile à ce titre.

Le verrouillage par jeton

Une approche intermédiaire consiste à exiger un jeton, transmis dans l'adresse ou dans un cookie, pour que le site accepte même d'afficher la page de connexion. Sans ce jeton, le serveur répond comme si la page n'existait pas. Cette technique combine la discrétion de la protection par le serveur et la souplesse d'une gestion applicative. Elle convient bien aux espaces réservés à une petite équipe. Le jeton doit être suffisamment long et distribué de façon sûre. Il ne remplace pas l'authentification, il la précède.

La séparation des sessions

Une session ouverte sur le site public ne doit pas donner accès à l'espace d'administration, ce qui suppose des cookies distincts et des durées différentes. Une durée courte pour la session d'administration, avec renouvellement à l'activité, limite l'exposition en cas de poste laissé sans surveillance. Le cookie doit être marqué comme inaccessible au script et réservé aux connexions sécurisées. La déconnexion doit invalider la session côté serveur et pas seulement supprimer le cookie. Ces détails techniques font la différence entre une protection réelle et une apparence de protection. Ils se vérifient en quelques minutes avec les outils du navigateur.

Construire un dispositif cohérent

L'empilement de mesures ne produit un résultat solide que si elles sont choisies et ordonnées avec méthode.

Définir ce que l'on protège

Un espace d'administration de site vitrine et une interface manipulant des données clients n'appellent pas le même niveau d'exigence. Le premier justifie une limitation des tentatives et un mot de passe fort, le second impose un second facteur et une journalisation complète. Formaliser cette exigence en une phrase évite de sur-protéger ou de sous-protéger. Elle guide également les arbitrages ultérieurs, lorsqu'une mesure gêne un utilisateur. Cette réflexion prend dix minutes et elle structure tout le reste. Elle mérite d'être écrite plutôt que gardée en tête.

Combiner trois couches minimum

Un dispositif raisonnable pour un site professionnel associe un mot de passe robuste, une limitation des tentatives et un second facteur pour les comptes à privilèges. Ces trois couches couvrent les scénarios les plus fréquents : essais automatisés, identifiants volés, réutilisation de mots de passe. Y ajouter une adresse de connexion non standard réduit le bruit sans effort. Au delà, le rendement décroît rapidement et la gêne augmente. Cette combinaison constitue un bon point d'équilibre pour la plupart des sites. Elle se met en place en une journée.

Ordonner les vérifications

Les contrôles les moins coûteux doivent intervenir en premier, pour rejeter les requêtes indésirables sans consommer de ressources. Vérifier la présence d'un jeton, puis le compteur de tentatives, puis les identifiants, puis le second facteur suit cet ordre naturel. Effectuer une requête en base avant de vérifier un compteur en cache gaspille des ressources sur les attaques volumineuses. Cet ordre a un effet réel sur la résistance à une attaque massive. Il ne coûte rien à respecter dès la conception. Le corriger après coup demande une réécriture.

Ne pas divulguer d'information

Les messages d'erreur ne doivent jamais indiquer si l'identifiant existe ou si seul le mot de passe est faux. Un message unique pour tous les cas d'échec empêche l'énumération des comptes valides. Le temps de réponse doit également rester constant, une vérification plus rapide sur un identifiant inexistant révélant l'information par un autre canal. Ces précautions paraissent excessives et elles sont exploitées en pratique. Elles ne coûtent que quelques lignes. Les ignorer facilite considérablement le travail d'un attaquant.

Prévoir les accès de secours

Un dispositif solide doit prévoir la situation où l'administrateur principal ne peut plus se connecter : appareil perdu, compte verrouillé, erreur de configuration. Un second compte administrateur, avec des identifiants conservés hors ligne, constitue le filet le plus simple. L'accès direct à la base ou au système de fichiers permet également de rétablir la situation. Documenter cette procédure de secours avant d'en avoir besoin est essentiel. Elle sera exécutée dans l'urgence, par quelqu'un qui n'aura pas le temps de réfléchir. Une page écrite suffit.

Journaliser sans excès

Enregistrer les connexions réussies et échouées, avec l'horodatage, l'identifiant tenté et l'adresse réseau, donne la visibilité nécessaire. Ces journaux contiennent des données personnelles et leur conservation doit être limitée dans le temps, généralement quelques mois. Ils doivent également être protégés, un attaquant cherchant souvent à les effacer. Une copie sur un système distinct répond à cette préoccupation sur les sites sensibles. Nous ne sommes pas juristes et la durée de conservation doit être arbitrée en fonction du contexte. Le principe de proportionnalité guide utilement cette décision.

Vérifier que la protection tient

Un dispositif non testé n'a qu'une valeur théorique, et les tests à mener sont simples.

Tenter d'accéder sans authentification

Le premier test consiste à ouvrir chaque adresse de l'espace protégé depuis un navigateur sans session, en navigation privée. Toute page qui s'affiche révèle un point d'entrée oublié. Ce test doit couvrir les pages secondaires, les traitements de formulaire et les points d'accès de données. Un inventaire exhaustif des adresses est donc nécessaire avant de commencer. Cette vérification révèle presque toujours au moins une omission. Elle se refait après chaque ajout de fonctionnalité.

Vérifier les droits par rôle

Une authentification réussie ne signifie pas que toutes les actions sont permises. Un contributeur ne doit pas pouvoir accéder aux réglages ni modifier les contenus d'autrui. Tester chaque rôle sur chaque fonction sensible constitue un exercice fastidieux et indispensable. Un tableau croisant les rôles et les fonctions permet de suivre cette vérification. Il sert ensuite de référence lors des évolutions. Les failles de ce type sont fréquentes et rarement détectées par les tests fonctionnels classiques.

Tester la limitation des tentatives

Enchaîner volontairement des connexions erronées permet de vérifier que le blocage se déclenche au seuil prévu et se lève après la durée annoncée. Il faut également vérifier que le blocage ne s'applique pas à l'ensemble des utilisateurs, situation catastrophique lors d'une attaque. Le test doit être mené depuis deux adresses différentes pour valider le comportement. Cette vérification prend cinq minutes et elle révèle régulièrement une configuration inopérante. Un compteur mal stocké se réinitialise à chaque requête. L'erreur est invisible sans ce test.

Contrôler le comportement des appels du site

Les fonctions publiques qui adressent des requêtes à l'espace d'administration doivent continuer de fonctionner. Formulaires, filtres, paniers et recherches en direct constituent les cas les plus courants. Un parcours complet du site public, en observant la console du navigateur, révèle les blocages. Cette vérification est la raison d'être de toute l'approche présentée ici et elle est parfois oubliée. Elle doit figurer dans la liste de contrôle au même titre que les tests de sécurité. Une fonction cassée est aussi grave qu'une faille pour l'activité.

Simuler une perte d'accès

Tester la procédure de secours en conditions réelles, sur un environnement de préproduction, valide sa faisabilité. Beaucoup de procédures documentées se révèlent inapplicables au premier essai, faute d'un accès ou d'un identifiant. Ce test doit être mené par une personne différente de celle qui a rédigé la procédure. Il révèle les étapes implicites et les prérequis non mentionnés. Le refaire une fois par an maintient la procédure valide. C'est une assurance dont le coût est dérisoire.

Reprendre les contrôles après chaque évolution

Une mise à jour, l'ajout d'une extension ou une modification de thème peuvent réintroduire un point d'entrée non protégé. Une liste de contrôle courte, reprise après chaque intervention structurante, évite la régression silencieuse. Cinq vérifications suffisent : accès sans session, droits par rôle, limitation des tentatives, second facteur et appels du site public. Cette liste tient sur une carte et elle se déroule en un quart d'heure. Sa régularité importe davantage que son exhaustivité. C'est ce qui distingue une protection réelle d'une protection installée un jour et oubliée.