Qu'est-ce que l'énumération d'utilisateurs WordPress via wp-json, et comment s'en protéger ?
Dernière vérification : 30 octobre 2026
L'énumération d'utilisateurs WordPress via wp-json consiste à interroger l'API REST intégrée au cœur WordPress (/wp-json/wp/v2/users) pour obtenir, sans authentification, l'identifiant, le nom affiché et le slug des comptes ayant publié du contenu. WordPress documente ce comportement depuis la version 4.7.1 (janvier 2017) : la version 4.7 initiale exposait les données de tout utilisateur ayant publié un article d'un type de contenu public, et 4.7.1 a restreint cette exposition aux seuls types de contenu explicitement configurés pour apparaître dans l'API REST — sans supprimer l'endpoint lui-même, qui reste accessible par conception (sources : wordpress.org, annonce de la version 4.7.1 ; developer.wordpress.org, référence de l'endpoint Users).
Vérifiez la sécurité globale de votre installation WordPress, en 30 secondes.
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
Ce que révèle une requête non authentifiée
Pour une requête anonyme, la documentation officielle de l'API REST WordPress (developer.wordpress.org) décrit un contexte "embed" qui renvoie, pour chaque utilisateur concerné : son identifiant numérique (id), son nom affiché (name), le lien vers son archive d'auteur (link), son slug, et son avatar (avatar_urls). Les champs plus sensibles (identifiant de connexion brut, email, rôles, capacités) restent réservés au contexte "edit", accessible uniquement à un utilisateur authentifié disposant des droits suffisants.
Deux chemins d'énumération, pas un seul
| Chemin | Ce qu'il révèle | Limite documentée |
|---|---|---|
| /wp-json/wp/v2/users | Identifiant, nom affiché, slug et lien d'archive de chaque auteur concerné | Limité, depuis WordPress 4.7.1, aux comptes ayant publié un contenu d'un type explicitement exposé dans l'API REST (source : wordpress.org) |
| /?author=N (redirection vers /author/slug/) | Le même type de slug, via la page d'archive publique de l'auteur | Ne fonctionne que si le compte a déjà publié au moins un contenu, donc une archive existe — mécanisme recoupé sur plusieurs ressources de sécurité indépendantes, non couvert par une page WordPress.org dédiée |
Pourquoi un identifiant de connexion découvert est un problème
Une attaque par force brute doit normalement deviner deux informations à la fois : l'identifiant de connexion et le mot de passe. Un identifiant confirmé publiquement réduit l'attaque à la seule recherche du mot de passe, ce qui raccourcit considérablement le temps nécessaire — surtout si ce même identifiant correspond à un compte administrateur.
Vérifiez votre installation WordPress
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
Comment limiter l'exposition
- Donnez à chaque compte administrateur un nom d'affichage et un slug différents de son identifiant de connexion, directement depuis son profil utilisateur.
- Restreignez, via une extension de sécurité dédiée ou un filtre personnalisé sur le hook officiel rest_endpoints (developer.wordpress.org, depuis WordPress 4.4), l'accès non authentifié à l'endpoint /wp/v2/users plutôt que de désactiver l'ensemble de l'API REST.
- Ne désactivez pas l'API REST dans son intégralité : l'éditeur de blocs et de nombreuses extensions en dépendent pour fonctionner (source : developer.wordpress.org).
- Utilisez des mots de passe réellement forts et une double authentification sur les comptes administrateur : même un identifiant connu ne suffit pas à un attaquant si le mot de passe résiste.
Ce que ScanMonSite vérifie à la place
Notre scanner ne teste pas l'énumération d'utilisateurs via /wp-json/wp/v2/users : ce point n'entre pas dans son périmètre actuel. Il détecte en revanche la présence de comptes administrateur créés sans autorisation une fois qu'un accès a déjà eu lieu — voir notre guide dédié ci-dessous.
Sources
Questions fréquentes
L'API REST de WordPress peut-elle être désactivée complètement ?
Ce n'est pas recommandé : l'éditeur de blocs (Gutenberg) s'appuie sur l'API REST pour chaque création, enregistrement ou aperçu de contenu (source : developer.wordpress.org, fonction use_block_editor_for_post_type). La désactiver entièrement casse l'édition de contenu, pas seulement l'endpoint des utilisateurs.
Le slug renvoyé par /wp-json/wp/v2/users est-il toujours mon identifiant de connexion ?
Par défaut, oui : WordPress utilise le nom de connexion comme base de ce slug, sauf si vous l'avez explicitement changé depuis le profil de l'utilisateur.
La redirection /?author=1 est-elle liée à l'API REST ?
Non, c'est un mécanisme distinct du cœur WordPress : il redirige vers l'archive d'auteur publique (/author/slug/) et révèle le même type d'information. Il n'est documenté officiellement par aucune page WordPress.org dédiée à ce comportement précis, mais il est largement recoupé par plusieurs ressources de sécurité indépendantes.
Un compte qui n'a jamais publié peut-il être découvert via wp-json ?
Non, l'endpoint /wp-json/wp/v2/users ne liste, depuis WordPress 4.7.1, que les comptes ayant publié un contenu d'un type explicitement exposé dans l'API REST (source : wordpress.org, annonce de la version 4.7.1).
Pourquoi un identifiant de connexion découvert est-il un problème en soi ?
Parce qu'il réduit une attaque par force brute à la seule recherche du mot de passe : l'attaquant n'a plus besoin de deviner les deux informations à la fois.
ScanMonSite teste-t-il l'énumération via /wp-json/wp/v2/users sur mon site ?
Non. Aucun module de notre scanner n'interroge cet endpoint pour tester l'énumération d'utilisateurs : ce point n'est pas couvert par notre analyse automatique actuelle.
Changer mon nom d'affichage protège-t-il mon identifiant de connexion ?
Seulement en partie : cela masque le nom affiché publiquement (champ name), mais pas nécessairement le slug de l'archive d'auteur si celui-ci reprend encore l'identifiant de connexion d'origine.
Pour aller plus loin
Vérifiez la sécurité de votre site WordPress
Gratuit, sans inscription — scan passif en lecture seule, aucune modification de votre site.
Votre site est déjà touché ? Demandez un devis de réparation.