Quand on parle de sécurité sur WordPress, l’énumération d’utilisateurs semble parfois “petite” face à des sujets plus spectaculaires comme l’exploitation d’une vulnérabilité. Pourtant, c’est souvent la porte d’entrée silencieuse qui rend les attaques plus faciles. Un attaquant qui arrive à identifier les comptes existants gagne du temps, améliore ses chances lors des tentatives d’attaque et peut cibler des profils précis (administrateur, éditeur, auteur actif).
L’idée n’est pas seulement de “cacher des noms”. Il s’agit surtout de réduire l’information divulguée par WordPress lors de certaines requêtes, et de limiter les comportements qui donnent des indices exploitables. Dans cet article, je vais détailler ce qu’on entend par énumération, où WordPress peut exposer des signaux, et comment construire une protection WordPress solide, pragmatique, et suffisamment sûre sans casser le site.
Comprendre l’énumération d’utilisateurs, et pourquoi ça marche
L’énumération d’utilisateurs, c’est la capacité à confirmer l’existence d’un compte à partir de réponses différentes produites par le site. Selon le cas, l’information peut être visible directement (messages d’erreur, pages qui changent) ou indirectement (codes HTTP, redirections, contenus qui varient).
Sur WordPress, deux grandes familles de scénarios reviennent souvent:
- Les requêtes qui cherchent des posts à partir d’un paramètre “auteur” ou d’un identifiant. Les endpoints exposés par l’API WordPress (souvent via REST), qui peuvent renvoyer des données sur des utilisateurs si rien n’est filtré.
Ce qui rend l’énumération utile pour un attaquant, c’est la différence de comportement. Un même pattern de requête produit un résultat “cohérent” si l’utilisateur existe, et un résultat “vide” ou “différent” s’il n’existe pas. Cette variation permet ensuite de construire une liste d’adresses, de noms d’affichage, ou simplement de confirmer un identifiant. Ensuite, on peut viser des mots de passe plus réalistes, lancer des campagnes de phishing mieux ciblées, ou optimiser les tentatives d’attaque.
Je l’ai déjà vu dans des audits: pas besoin de casser une appli entière. Il suffit parfois de quelques endpoints trop permissifs pour qu’un script externe récolte des dizaines de comptes en un temps raisonnable. Le site, lui, semble “fonctionner”. C’est juste l’information qui fuit.
Les points d’exposition fréquents sur WordPress
WordPress n’est pas “insecure” par défaut sur l’énumération, mais il existe des configurations, des plugins, et des comportements historiques qui peuvent donner des signaux.
1) Le paramètre d’auteur dans les archives
Un grand classique: /?author=NUM ou des URLs d’archives d’auteurs. Dans certaines configurations, WordPress peut renvoyer une archive différente selon que l’ID correspond à un utilisateur valide, ou selon que cet utilisateur a des contenus publiés.
Même lorsque l’URL renvoie une page “pas trouvée”, la différence peut être mesurable via le code HTTP, la redirection, ou la présence d’un nom d’auteur dans le contenu rendu.
Ce n’est pas forcément lié à une “faute” unique. Souvent, le problème vient de la combinaison entre un thème, des paramètres de visibilité, et des règles de cache côté serveur ou CDN.
2) Les réponses de l’API REST (wp-json)
WordPress expose une API REST via wp-json. Selon la version, la configuration, et surtout les rôles, certains endpoints peuvent divulguer des informations. L’énumération se produit quand une requête non authentifiée obtient une réponse contenant des champs exploitables (ID, nom, slug, rôles, ou même des métadonnées).
Le piège courant: “l’API est activée, donc c’est pratique”. Oui, mais ce n’est pas automatique pour tous les endpoints, et certains plugins ajoutent des routes supplémentaires. Il faut vérifier ce que renvoie votre site dans un contexte sans identifiant de session.
3) XML-RPC et interactions indirectes
XML-RPC est plus ancien, et il a été la cible de plusieurs attaques par le passé. Aujourd’hui encore, il peut être activé selon les installations. Même si l’énumération n’est pas toujours directement “lire la liste des utilisateurs”, des interactions indirectes peuvent aider à confirmer l’existence d’un compte dans le cadre de tentatives d’authentification ou de certaines méthodes.
Le point important ici n’est pas seulement “XML-RPC est activé ou non”, mais ce que votre site accepte réellement, et si des restrictions existent.
4) Plugins, thèmes, et scripts front qui ajoutent des endpoints
Un WordPress “standard” peut être raisonnablement bien configuré, puis un plugin introduit une route API, un shortcode, ou un comportement Ajax qui divulgue des informations. La plupart du temps, l’énumération vient d’une petite fonctionnalité.
J’ai déjà vu des cas où l’URL d’un autocomplétion d’auteur (pour une recherche interne) renvoyait des identifiants, puis un attaquant transformait ça en liste. Ce n’est pas le cœur WordPress qui est en cause, c’est la surface étendue.
Ce qu’il faut viser exactement (et ce qu’il ne faut pas casser)
Avant d’appliquer des mesures, il est utile de clarifier l’objectif. Empêcher l’énumération ne signifie pas “rendre toutes les pages identiques”. Sur un site réel, on veut conserver la navigation, la recherche, et certaines fonctionnalités d’administration pour les utilisateurs authentifiés.
L’objectif raisonnable, c’est de:
- Réduire la différence de réponse entre “utilisateur existant” et “utilisateur inexistant”. Limiter la disponibilité des données utilisateur aux seuls cas authentifiés ou autorisés. Empêcher les requêtes automatisées d’explorer massivement en limitant le débit et en ajoutant des protections réseau.
En pratique, certaines mesures peuvent impacter le référencement si elles modifient trop agressivement les routes d’archives d’auteurs. D’autres peuvent casser des appels front-office si un plugin s’appuie sur des endpoints REST ouverts. D’où l’importance de tester avec votre configuration réelle.
Mesures techniques côté WordPress (sans magie)
Il existe plusieurs approches. Les plus efficaces combinent des filtrages (au bon endroit dans WordPress) et des contrôles (qui limite et log).
Bloquer ou neutraliser les comportements liés à author=
Selon votre thème et votre version, neutraliser les archives d’auteur peut réduire les signaux. L’idée n’est pas forcément de supprimer l’accessibilité des pages d’auteur pour les visiteurs légitimes, mais de garantir que l’existence d’un ID ne se traduit pas par une variation exploitable.
Concrètement, on peut:
- S’assurer que les requêtes qui ciblent author ne renvoient pas d’éléments variables (comme un nom d’auteur) quand l’utilisateur ne devrait pas être “visible”. Vérifier les redirections et codes HTTP. Quand WordPress renvoie une archive valide pour un auteur existant mais sans contenu, l’attaquant obtient un indice. Si votre site n’utilise pas ces archives, vous pouvez durcir. Ajuster la façon dont la requête est traitée via les hooks WordPress, au lieu de faire du “masquage CSS” (inefficace contre l’exploitation).
En pratique, le meilleur point d’ancrage dépend du comportement exact observé. C’est pour ça que je recommande toujours de commencer par observer ce que renvoie votre site sur des IDs inexistants et existants.
Restreindre les endpoints REST qui exposent des utilisateurs
Pour la protection WordPress, la voie la plus nette passe par l’API REST. Il faut:
- Vérifier quels endpoints de type “users” ou “search” répondent sans authentification. Contrôler les champs renvoyés. Bloquer ou filtrer les réponses pour les rôles non autorisés.
Attention aux faux positifs. Certains sites s’appuient sur un endpoint REST pour afficher des profils d’auteurs dans le front. Si vous coupez un endpoint utile, vous casserez une fonctionnalité. La bonne méthode consiste à appliquer une règle fine, ou à remplacer l’appel front par un endpoint côté serveur (ou à authentifier l’accès si c’est acceptable).
Une approche prudente consiste à désactiver les routes inutiles introduites par des plugins et à limiter l’exposition des endpoints natifs qui ne servent pas votre cas.
Désactiver ce qui ne sert pas: XML-RPC, et réduire la surface
Désactiver XML-RPC quand vous ne l’utilisez pas est souvent un bon gain de sécurité. Cela ne règle pas à lui seul l’énumération via les archives d’auteur, mais ça réduit des chemins d’attaque connexes et diminue le bruit global.
De manière similaire, si une fonctionnalité WordPress ou un plugin n’est pas utilisée, la meilleure stratégie est de la désactiver plutôt que de compenser en aval.
Mesures côté serveur et réseau: le “frein” qui change tout
Même si vous neutralisez des signaux, un attaquant peut continuer à essayer. La différence, c’est que vous voulez rendre l’exploration trop coûteuse, trop lente, ou trop instable.
Rate limiting et filtrage
Mettre en place un rate limiting sur:
- les endpoints REST non authentifiés, les pages qui peuvent répondre différemment à des requêtes author, les pages de connexion et les tentatives d’authentification,
Réduit drastiquement la capacité de moissonner des IDs.
Côté WordPress, vous pouvez parfois vous appuyer sur le reverse proxy (Nginx, Apache, ou une couche CDN/WAF) pour imposer un débit. Côté hébergement, des outils comme fail2ban, ou des protections intégrées peuvent jouer.
WAF et règles ciblées
Un WAF peut faire plus que bloquer des signatures. Il peut aussi détecter des patterns de requêtes répétées. Pour l’énumération, le pattern est souvent “beaucoup de requêtes très similaires, avec des IDs qui changent”.
Le piège, c’est d’être trop agressif. Si vos utilisateurs légitimes font une recherche interne qui ressemble à une exploration, vous pourriez les bloquer. C’est pour ça que je privilégie les règles qui ciblent spécifiquement les endpoints sensibles, et pas juste “tout ce qui ressemble à une attaque”.
Ce que je vérifie systématiquement sur un site existant
Avant de modifier quoi que ce soit, je fais un mini diagnostic “par le comportement”. C’est souvent plus rapide que de partir d’hypothèses.
Voici ce que vous pouvez observer sans outils avancés, juste avec une navigation prudente, des requêtes test, et un peu de logique:
Testez des IDs d’auteur plausibles dans /?author=NUM et comparez le code HTTP, la présence d’un nom d’auteur, et le contenu minimal de la page. Ouvrez wp-json en mode non authentifié, puis cherchez les endpoints qui renvoient des objets utilisateur ou des résultats de recherche “users”. Regardez les pages et ressources qui chargent des profils d’auteurs dans le front, pour repérer si un appel REST est exposé. Analysez les logs (au moins pendant 24 à 48 heures) pour repérer des répétitions sur les endpoints sensibles, même sans “activité visible”. Vérifiez les plugins récents: ceux qui ajoutent une recherche d’utilisateurs, des abonnés, une modération, ou des listes d’auteurs.Cette phase est utile, parce que la “bonne” mesure dépend totalement des signaux que votre site émet réellement.
Une stratégie réaliste, étape par étape
La meilleure protection WordPress est rarement une seule action spectaculaire. C’est un enchaînement cohérent. Voici une séquence que j’utilise souvent, parce qu’elle minimise les risques de casser le site et maximise l’impact.
Identifier les points exacts qui trahissent l’existence d’un utilisateur (archives d’auteur, REST users, routes ajoutées par plugins). Corriger côté WordPress en filtrant les réponses ou en neutralisant les différences exploitables, sans supprimer les fonctionnalités légitimes. Limiter l’accès au REST non authentifié en réduisant les endpoints exposés, ou en exigeant l’authentification si c’est approprié. Activer une limitation de débit sur les endpoints concernés et sur la connexion, au niveau serveur ou via WAF/CDN. Surveiller après déploiement, pendant quelques jours, pour valider qu’on réduit bien l’énumération sans casser le fonctionnement front.Je préfère cette approche parce qu’elle donne un résultat mesurable. Et elle évite la tentation de “tout désactiver” d’un coup, ce qui finit souvent en tickets support.
Trade-offs importants (ceux qu’on découvre trop tard)
Masquer trop fort les archives d’auteur
Si votre thème dépend des pages d’auteur pour des fonctionnalités (liens dans le pied de page, pages indexées, widgets “auteurs”), une neutralisation trop radicale peut pénaliser le référencement ou créer des pages incohérentes. Dans certains cas, la bonne solution est de réduire les signaux pour les IDs non valides, pas de rendre toutes les archives d’auteur identiques.
Couper un endpoint REST “par sécurité”
Beaucoup de plugins utilisent wp-json pour des calendriers, des filtres, ou de l’affichage dynamique. Si vous bloquez un endpoint “users”, vous pouvez casser un composant qui existait depuis longtemps sans que personne ne sache qu’il dépend de l’API.
La logique que je privilégie: filtrer seulement ce que vous devez, ou protéger les routes exposées qui ne sont pas nécessaires au front public.
Logs et vie privée
Limiter l’énumération implique parfois de mieux tracer. Attention à la conservation des logs, et à la manière dont vous gérez les données. Sur des sites en conformité renforcée (RGPD), la durée de conservation et l’accès aux logs peuvent devoir être encadrés.
Cas particuliers: multisite, rôles, et sites à auteurs multiples
Sur WordPress multisite, la surface peut se multiplier. Une énumération peut viser non seulement les utilisateurs, mais aussi les rôles dans un sous-site donné, ou des différences de réponse entre blogs.
De plus, sur un site éditorial avec beaucoup d’auteurs, les archives d’auteur sont souvent utilisées. Dans ce contexte, l’objectif “supprimer les archives d’auteur” est rarement réaliste. On cherche plutôt à supprimer les indices exploitables sur les IDs non valides et à restreindre les endpoints REST.
Une bonne approche consiste à tester précisément avec des comptes de rôles différents. Un utilisateur authentifié n’est pas un visiteur public, et les réponses peuvent être légitimement différentes.
https://gardewp.fr/securite-wordpress/Comment savoir si votre correction marche vraiment
Après modification, il faut valider que l’énumération devient difficile. Sans tomber dans les tests interminables, je fais en général:
- des requêtes répétées sur quelques IDs d’auteur et comparaison stricte des réponses (contenu minimal, code HTTP, redirections), un test de non authentifié sur les endpoints REST liés aux utilisateurs, une vérification fonctionnelle côté front (profil auteur, widgets, recherche si elle existe), et une observation sur les logs pour voir si le trafic automatisé change de comportement.
Si, avant correction, un script pouvait “deviner” l’existence d’un compte par la différence de contenu, après correction, la différence doit disparaître ou devenir trop floue pour un script simple. Le “trop floue” dépend de votre niveau de protection, mais l’idée reste identique.
Plugins et “protection” prête à l’emploi: utile, mais à vérifier
Oui, il existe des plugins qui promettent d’empêcher l’énumération. Dans certains cas, c’est très efficace et suffisant. Dans d’autres, ça apporte surtout un masque ou une logique partielle, et ça finit par être contourné sur une autre route.
Mon conseil: si vous utilisez un plugin, traitez-le comme une brique de plus, pas comme une garantie totale. Vérifiez ce qui est couvert. Ensuite, testez réellement sur les URLs et endpoints qui exposent chez vous.
La protection WordPress la plus solide, celle qui tient sur le long terme, vient souvent d’une combinaison entre paramétrage (et plugin quand il est fiable), durcissement sur les endpoints, et protections réseau.
Ce qu’il faut retenir
Empêcher l’énumération d’utilisateurs sur WordPress, ce n’est pas “cacher un nom”. C’est réduire l’information exploitable que le site renvoie quand on explore des paramètres comme les IDs d’auteur, ou quand on interroge l’API REST et les routes exposées par des plugins.
Les meilleurs résultats viennent d’une logique simple: identifier vos signaux, corriger à la source au niveau WordPress, puis ajouter un frein côté serveur. Vous obtenez une protection WordPress plus robuste, moins dépendante d’un seul réglage, et surtout plus durable quand le site évolue.
Si vous voulez, décrivez votre configuration (multisite ou non, plugins qui touchent à la recherche d’auteurs ou à l’API REST, et ce que vous observez sur /?author=ID ou wp-json). Je peux vous aider à cibler les points à corriger en priorité sans casser votre front.