# Énumération des utilisateurs WordPress : ?author= et /wp/v2/users

> Deviner qui sont vos administrateurs prend trente secondes à un attaquant. Comment fermer ces portes sans abîmer l'API REST ni le SEO.

- Auteur : Clément Hadrot
- Publié le : 2020-12-17
- Mis à jour le : 2020-12-17
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/enumeration-utilisateurs-wordpress/

## L’essentiel

- ?author=1 révèle le pseudo réel d'un compte par simple redirection
- /wp/v2/users liste les auteurs sans authentification par défaut
- Les correctifs efficaces évitent de casser les articles ou le SEO

Avant de lancer une attaque par force brute contre un site WordPress, un attaquant sérieux commence presque toujours par la même chose : découvrir les identifiants de connexion réels des comptes existants. Deviner un mot de passe est difficile ; deviner un nom d'utilisateur l'est beaucoup moins quand le site le révèle lui-même sans qu'on ait rien demandé.

Deux mécanismes natifs de WordPress facilitent cette découverte, qu'on appelle énumération des utilisateurs : le paramètre d'URL `?author=` et l'endpoint `/wp/v2/users` de l'API REST. Comprendre leur fonctionnement permet de les fermer sans casser des fonctionnalités auxquelles ils sont parfois utiles.

## La faille par ?author=

WordPress génère une archive publique pour chaque auteur, accessible via une URL du type `https://exemple.fr/?author=1`. Par défaut, le cœur redirige cette URL vers l'archive propre de l'auteur, dont le chemin contient généralement son *nicename*, une variante du pseudo utilisé pour construire les URL. En testant successivement `author=1`, `author=2`, `author=3`, un script automatisé obtient en quelques secondes la liste des identifiants réels associés à chaque compte, y compris souvent celui de l'administrateur principal créé à l'installation.

Le premier compte créé porte presque toujours l'identifiant numérique 1, ce qui en fait la cible privilégiée de ce genre de sondage.

## La faille via l'API REST

Depuis WordPress 4.7, l'API REST expose par défaut l'endpoint `/wp-json/wp/v2/users`, qui liste les utilisateurs ayant publié au moins un contenu, avec leur identifiant, leur *slug* et leur nom affiché, sans authentification préalable requise :

```
curl https://exemple.fr/wp-json/wp/v2/users
```

Ce comportement est documenté et volontaire côté WordPress.org : l'API expose les informations publiques des auteurs de contenu, dans la logique où ces informations apparaissent de toute façon sur les pages d'archive d'auteur. Cela n'empêche pas que, combinée à l'archive par `?author=`, cette information accélère considérablement le travail d'un attaquant qui prépare une attaque par force brute ciblée.

> L'essentiel à retenir : ?author=1 révèle le pseudo réel d'un compte par simple redirection ; /wp/v2/users liste les auteurs sans authentification par défaut ; Les correctifs efficaces évitent de casser les articles ou le SEO

## Fermer la porte sans casser l'API REST

Désactiver entièrement l'API REST est une réponse disproportionnée : de nombreuses extensions et le bloc éditeur lui-même en dépendent pour fonctionner. La bonne approche consiste à filtrer spécifiquement l'endpoint des utilisateurs pour les visiteurs non authentifiés, via le filtre `rest_endpoints` :

```
add_filter( 'rest_endpoints', function ( $endpoints ) {
    if ( ! is_user_logged_in() ) {
        unset( $endpoints['/wp/v2/users'] );
        unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
    }
    return $endpoints;
} );
```

Les utilisateurs connectés, y compris les auteurs qui utilisent cet endpoint depuis l'éditeur de blocs pour sélectionner un auteur, conservent un accès normal. Seuls les visiteurs anonymes perdent la possibilité de lister les comptes.

## Fermer la porte sans casser le SEO ni les liens existants

Pour `?author=`, la solution la plus robuste consiste à intercepter la requête avant la redirection native, plutôt que de désactiver purement et simplement les archives d'auteur (ce qui casserait les liens déjà indexés par les moteurs de recherche si le site les utilise réellement) :

```
add_action( 'template_redirect', function () {
    if ( is_author() && isset( $_GET['author'] ) && ! is_user_logged_in() ) {
        wp_safe_redirect( home_url( '/' ), 301 );
        exit;
    }
} );
```

Cette redirection ne bloque que l'accès direct par identifiant numérique brut ; si le site publie réellement des archives d'auteur utiles (blog collectif, magazine), il convient d'adapter la condition pour ne cibler que les tentatives de sondage systématique plutôt que l'usage légitime.

## Ce qui ne suffit pas

- Renommer simplement l'identifiant affiché de l'administrateur sans traiter l'énumération elle-même ne fait que ralentir légèrement un attaquant motivé.
- Une extension de « masquage » qui cache l'écran de connexion sans traiter ces deux portes laisse l'énumération intacte.

> Fermer une porte d'énumération ne remplace jamais un mot de passe solide et une limitation des tentatives de connexion : c'est un obstacle de plus, pas un rempart à lui seul.

## En résumé

L'énumération des utilisateurs via `?author=` et l'API REST reste l'une des premières étapes d'une attaque automatisée contre WordPress. Les deux se corrigent proprement en quelques lignes, sans désactiver de fonctionnalités utiles aux visiteurs connectés ni pénaliser un référencement déjà construit sur les archives existantes du site.