L’énumération des utilisateurs, sur WordPress, n’est pas un scénario de laboratoire. C’est un levier concret pour passer de “j’ai un site” à “je sais qui sont les comptes valides”, puis d’enchaîner avec du ciblage, du phishing, ou une prise de mot de passe plus efficace. Ce n’est pas seulement une question de “sécurité du login”, c’est aussi une question de ce que le site laisse fuiter via les URL, l’API, le contenu public, et même le comportement des pages de récupération.
Dans un durcissement WordPress, l’objectif n’est pas forcément d’empêcher toute forme de découverte (certains éléments font partie du fonctionnement normal du CMS). L’objectif raisonnable, c’est de réduire la surface où un attaquant peut confirmer rapidement qu’un identifiant existe, et de rendre cette confirmation moins fiable, moins pratique, ou plus coûteuse.
D’où vient l’énumération, concrètement
Sur WordPress, l’énumération apparaît rarement sous une seule forme. En pratique, on observe plusieurs “portes” qui, combinées, donnent une vision assez précise des comptes.
1) Les URL d’auteur et les archives
Si votre site expose des pages d’auteur, un attaquant peut tester des identifiants et constater si le résultat change. Deux symptômes classiques :
- des pages qui existent quand on tente une valeur donnée (ou un slug d’auteur) des pages qui renvoient 404 quand la valeur est incorrecte
Sur certains thèmes, l’auteur est visible sur les articles, et la page d’archive de l’auteur est accessible. Si cette archive est aussi indexable, l’attaquant obtient parfois des noms d’utilisateurs à partir du moteur de recherche, sans même avoir besoin de “bruteforcer”.
Il y a une nuance importante : empêcher les archives d’auteur peut avoir un impact SEO et éditorial. Mais si l’organisation considère que l’équipe n’a pas vocation à être identifiée, c’est un arbitrage légitime.
2) La récupération de mot de passe et les messages
Lorsqu’un site permet la récupération via email, le risque, c’est la différence entre “l’email n’existe pas” et “un email a été envoyé”. WordPress a longtemps eu des comportements qui pouvaient aider un acteur malveillant à valider des comptes. Le principe de durcissement consiste à faire en sorte que la réponse soit identique, quel que soit l’email.
La bonne nouvelle, c’est que WordPress prévoit un mécanisme dédié dans wp-config.php : DISALLOW_USER_ENUMERATION. Sans entrer dans les détails de versions, l’idée est simple, rendre l’interface de récupération non confirmante.
3) REST API et endpoints utilisateurs
L’API REST peut divulguer plus que prévu si elle est activée sans contrôle strict. Même quand l’endpoint “utilisateurs” ne renvoie pas tout, il peut révéler des métadonnées utiles à l’énumération, surtout si l’authentification n’est pas requise de façon cohérente.
Autre point qui revient souvent en audit : l’API REST n’est pas forcément “ouverte à tout le monde” au sens strict, mais des routes peuvent renvoyer plus que prévu selon les rôles, les paramètres, ou les configurations de plugins. Un durcissement sérieux passe par l’inventaire réel des routes exposées, pas uniquement par des hypothèses.
4) XML-RPC
XML-RPC est une ancienne brique de WordPress. Il n’est pas “en sécurité par magie”, et il a historiquement servi de terrain à des abus (connexion, amplification, tentatives d’accès). Même si l’énumération n’est pas le but direct de tous les abus, il contribue à une surface d’attaque où un acteur peut faire des tests répétés plus facilement.
Beaucoup d’organisations finissent par désactiver XML-RPC si elles n’en ont pas besoin. Sur des sites éditoriaux classiques, l’usage est souvent inutile.
5) Les plugins, pas le core
C’est un point que j’ai vu trop souvent : le core WordPress est raisonnablement durci, mais un plugin d’authentification, un plugin de gestion des utilisateurs, ou un thème qui expose un annuaire peut réintroduire une fuite. L’énumération peut alors provenir de :
- un formulaire custom un endpoint “search users” une page “mentions” ou “équipe” qui affiche un identifiant interne une API interne qui ne filtre pas correctement
Dans un durcissement WordPress, il faut traiter l’énumération comme un problème d’écosystème, pas seulement de fichiers wp-admin et d’options.
Commencer par le bon diagnostic (sans paniquer)
Avant de “tout couper”, je recommande une approche pragmatique. On ne veut pas détruire des fonctionnalités légitimes, ni passer deux semaines à modifier des réglages sur le papier.
Le plus efficace, c’est de vérifier trois choses :
Qu’est-ce que le site permet réellement de découvrir sans authentification ? Est-ce que les pages d’erreur sont identiques selon l’input (email, identifiant, slug) ? Qu’est-ce que l’API et les pages publiques révèlent comme informations ?Pour la partie pratique, vous pouvez tester, à partir d’un poste distinct, avec des comptes fictifs (des adresses non réelles, ou des utilisateurs temporaires sur un environnement de test). L’idée n’est pas de “réaliser un exploit”, mais de comparer les réponses. Si l’interface distingue trop clairement “compte inconnu” vs “compte existant”, vous tenez un levier.
Durcissement WordPress : actions concrètes
Voici ce qui donne souvent le meilleur ratio effort, risque réduit, sans casser le site.
1) Activer DISALLOW_USER_ENUMERATION dans wp-config.php
C’est l’action la plus directe contre l’énumération via la récupération. Dans wp-config.php, ajoutez ou vérifiez l’existence de la constante :
Define('DISALLOW_USER_ENUMERATION', true);À partir de là, la page de perte de mot de passe et les messages associés doivent rester non confirmants. Le point à surveiller, c’est l’expérience utilisateur côté légitime : les gens doivent toujours recevoir un message utile (au moins “un email a été envoyé si le compte existe”), sans que le site confirme l’existence du compte.
Si vous utilisez un plugin qui redéfinit la récupération de mot de passe, gardez un œil sur ce comportement, car certains surchargent les formulaires.
2) Réduire la visibilité des archives d’auteur
Deux stratégies existent, et elles ne donnent https://gardewp.fr/securite-wordpress/ pas le même résultat :
- empêcher l’accès aux archives d’auteur garder l’expérience éditoriale mais supprimer les indices utiles à l’énumération
Le premier choix est plus radical, le second demande plus de soins.
Dans un durcissement “orienté réduction de surface”, une approche fréquente consiste à désactiver ou rediriger les archives d’auteur. En pratique, cela peut se faire via des modifications dans votre thème (ou un plugin léger) pour que les liens d’auteur ne pointent plus vers des pages d’archive, et pour que ces pages ne répondent pas d’une manière utile à un attaquant.
Je le dis franchement : si votre contenu affiche un nom d’auteur en clair sur chaque article, vous ne supprimez pas l’information, vous supprimez surtout le mécanisme “test de valeurs” via URL. C’est souvent suffisant pour empêcher une énumération rapide.
Trade-off : si vous avez du trafic SEO sur ces pages, il faudra gérer les redirections proprement.
3) Mettre des garde-fous sur l’API REST
Le durcissement REST se fait généralement à deux niveaux :
- restreindre l’accès aux routes sensibles éviter d’exposer des données inutiles à des requêtes anonymes
Ce que je privilégie dans un audit, c’est de vérifier les routes réellement accessibles sans authentification, puis de décider selon votre besoin métier. Pour beaucoup de sites, l’API REST est surtout utilisée en interne, via l’admin, ou par l’édition. Dans ce cas, limiter les endpoints publics est logique.
Selon votre configuration, vous pouvez aussi limiter certains usages côté serveur, ou bloquer certaines fonctionnalités qui n’apportent aucune valeur aux visiteurs.
Edge case : certains plugins front utilisent l’API REST. Si vous bloquez trop large, vous allez casser une recherche, un formulaire, ou un affichage dynamique.
4) Désactiver XML-RPC si vous n’en avez pas l’usage
Si vous n’utilisez ni applications externes via XML-RPC, ni connecteurs spécifiques, le désactiver réduit une surface d’attaque. L’impact est généralement faible pour un site éditorial standard, mais il faut être sûr avant de le faire.
J’ai déjà vu des cas où un outil de publication externe s’appuyait sur XML-RPC sans que l’équipe le sache. La vérification passe par la documentation interne, ou par la liste des clients qui publient sur le site. Une fois confirmé que ce n’est pas utilisé, la désactivation est souvent un bon gain.
5) Uniformiser les réponses et les codes côté login
Même sans toucher au core, certains setups finissent par renvoyer des différences subtiles : temps de réponse, contenu de réponse, redirections. Pour l’énumération, c’est la différence qui compte.
Là où je suis prudent : “uniformiser” ne veut pas dire “rendre la page lente”. Ajouter une latence artificielle peut être contre-productif (UX, charge serveur). Le bon angle, c’est surtout de vérifier que le site ne renvoie pas un message confirmant l’existence du compte, et que vos pages custom n’ajoutent pas de variation selon l’utilisateur.
Un petit plan de contrôle, utile en mission
Plutôt que de tout appliquer sans vérifier, j’utilise un ordre qui évite les mauvaises surprises.
- Vérifier la récupération de mot de passe, avec un email existant et un email inexistant, et comparer le message final Tester l’accès aux pages d’auteur (y compris via des valeurs qui semblent plausibles) et noter le comportement (404, redirect, page réelle) Vérifier les endpoints REST sensibles accessibles sans authentification, au minimum ceux liés aux utilisateurs Vérifier si XML-RPC est nécessaire, puis le désactiver si ce n’est pas le cas Contrôler les plugins qui touchent l’authentification, la recherche d’utilisateurs, ou les annuaires front
Cette liste tient en une demi-journée si le site est simple, mais elle évite les actions “au hasard”.
Là où ça devient délicat : l’équilibre entre sécurité et fonctionnement
L’erreur la plus fréquente, c’est de traiter l’énumération comme un problème binaire : soit on bloque tout, soit on expose tout. En réalité, l’énumération est un gradient.
Bloquer les pages d’auteur, oui, mais pas en cassant le site
Si vous mettez des redirections massives, vous risquez :
- de casser des liens internes de provoquer des boucles d’endommager l’indexation
Un durcissement propre fait plutôt disparaître le mécanisme d’essai, tout en gardant un comportement stable.
Une bonne pratique consiste à s’assurer que les liens d’auteur présentés aux visiteurs ne mènent pas vers des pages qui donnent des confirmations (ou, à défaut, que ces pages ne sont pas accessibles publiquement si votre modèle éditorial ne l’exige pas).
REST API : limiter sans casser les plugins
Beaucoup de plugins front, même “simples”, utilisent REST pour chercher, filtrer, ou construire des vues. Lorsqu’on durcit, on doit partir de la réalité.
Mon approche est de limiter les routes sensibles plutôt que de bloquer tout l’API REST. Ensuite, on observe. Si une fonctionnalité se casse, on réajuste au niveau précis, pas global.
Le message de login : uniforme, mais pas “muet”
Uniformiser les réponses ne veut pas dire ne rien dire. Un message “si le compte existe, un email sera envoyé” donne une information actionnable et non confirmante.
En revanche, des messages distincts du type “le nom d’utilisateur n’existe pas” ou “vous n’êtes pas inscrit” sont précisément ce que vous voulez éviter. WordPress peut déjà vous aider, mais les plugins peuvent aussi contourner cette garde-fou.
Pièges fréquents vus sur le terrain
Je me méfie de trois catégories de configurations.
Les “sécurités” qui bloquent seulement le formulaire, mais pas l’accès aux données ailleurs. Un endpoint peut rester accessible, même si l’interface a été durcie. Les thèmes qui affichent des identifiants internes visibles. Même si la page d’archive est fermée, un attribut dans le HTML peut donner de la matière à l’énumération. Les règles WAF ou pare-feu trop agressives. Elles peuvent bloquer des requêtes légitimes, et compliquer le diagnostic (“est-ce que le site est sécurisé, ou est-ce qu’il est juste bloqué ?”).
Le durcissement, c’est une série de décisions cohérentes, pas une seule bascule.
Exemple de stratégie réaliste, selon votre contexte
Imaginons deux sites.
Site éditorial classique
- auteurs visibles sur les articles pas de besoin d’annuaires API REST non indispensable côté public
Ici, un durcissement efficace est souvent : activer DISALLOW_USER_ENUMERATION, désactiver ou rendre moins accessible l’archive d’auteur, et vérifier l’accès REST. XML-RPC peut être désactivé si aucun outil ne dépend de lui.
Site communautaire
- rôles, pages d’utilisateurs, pages de profil interaction entre visiteurs données d’utilisateurs nécessaires
Dans ce cas, vous ne pouvez pas “fermer” les pages d’auteur sans casser le produit. Le durcissement passe plutôt par : uniformiser les réponses, limiter strictement les endpoints de données, protéger l’API, et surveiller les tentatives répétées. L’énumération reste un risque, mais on réduit la capacité à confirmer des identifiants de manière automatisée.
C’est le même principe que pour une boutique physique : si vous ouvrez la vitrine, vous acceptez une visibilité. Vous vous concentrez sur l’empêchement des prises de décision rapides par un attaquant, plutôt que sur l’effacement total du public.
Comment vérifier que l’énumération est vraiment réduite
La vérification la plus honnête ne se limite pas à regarder “si le site est bloqué”. Il faut tester le niveau de confirmabilité.
Concrètement, comparez :
- message écran identique en cas de récupération avec email existant vs inexistant (si DISALLOW_USER_ENUMERATION est en place) comportement identique quand vous testez des valeurs d’auteur (ou absence de mécanique de test pour un visiteur normal) absence de réponses utiles sur les endpoints sensibles accessibles sans authentification
Si une différence persiste, elle ne signifie pas forcément que “tout est perdu”. Parfois, la fuite se déplace, par exemple d’une page vers une API, ou d’une API vers un plugin. C’est pour cela que l’inspection complète compte plus qu’une action unique.
Le rôle des journaux et du monitoring
Un durcissement “défensif” inclut aussi la détection. Même si vous réduisez l’énumération, des tentatives peuvent continuer, notamment parce que des attaquants utilisent déjà des listes d’utilisateurs ou des méthodes OSINT.
Sur WordPress, l’enjeu est d’avoir des logs exploitables :
- tentatives répétées de récupération de mot de passe requêtes nombreuses vers des URL d’auteur accès anormaux aux routes REST tentatives XML-RPC si le service est encore actif
Je ne vous conseille pas de noyer l’équipe sous des alertes inutiles. Le bon réglage consiste à corréler des patterns, pas à notifier sur chaque requête. Souvent, un seuil simple sur la répétition sur un court laps de temps suffit à faire ressortir une énumération en cours.
Ce que vous ne pouvez pas éliminer complètement
Il faut garder une exigence : aucune mesure ne garantit une invisibilité totale de l’existence de comptes.
Dès que votre site affiche des informations publiques sur des auteurs, l’information n’est pas “sécrétable” par définition. Ce que vous pouvez viser, c’est de rendre l’énumération automatisée difficile. En pratique, c’est là que la différence se joue, car un attaquant cherche une confirmation rapide, fiable, et reproductible.
Le durcissement WordPress contre l’énumération consiste donc à :
- supprimer ou réduire les réponses confirmantes limiter l’accès aux données via l’API réduire les surfaces de test (archives d’auteur, endpoints, fonctionnalités inutiles) garder une cohérence de comportement entre cas valides et invalides
Une dernière vérification avant de publier vos changements
Quand vous modifiez des aspects d’authentification ou d’URL (archives d’auteur, API REST, récupération), faites un test fonctionnel, côté utilisateur légitime :
- un utilisateur doit pouvoir demander un lien de récupération un administrateur doit pouvoir gérer ses contenus sans casser l’expérience les pages importantes doivent rester accessibles les plugins front dépendants d’une API doivent fonctionner
C’est bête à dire, mais j’ai vu des sites “sécurisés” qui ont perdu une fonctionnalité essentielle juste après durcissement. L’équipe a ensuite compensé en ajoutant des exemptions, parfois trop larges. Résultat, l’architecture perd en cohérence.
Traitez la réduction de l’énumération comme une amélioration contrôlée, pas comme un chantier isolé.
Si vous voulez, décrivez-moi votre configuration (thème custom ou non, plugins d’authentification, utilisation éventuelle de REST côté front, besoin d’archives d’auteur). Je pourrai vous proposer un plan de durcissement plus ciblé, en minimisant les risques de casser le site.