Désactiver l’accès anonyme à l’API REST introduit sous WordPress 4.7

WordPress 4.7 introduit une API REST qui est une avancée que beaucoup qualifient de révolutionnaire.

Elle permet à de nombreuses extensions, à des applications tierces ou encore à des services dans le cloud de communiquer facilement avec votre site Internet sous WordPress, et l’éditeur de blocs s’appuie lui aussi sur elle. L’inconvénient majeur dont s’est fait l’écho Wordfence sur son blog est qu’une telle API permet à n’importe quel visiteur anonyme d’obtenir la liste des auteurs de votre site… ce qui n’est pas sans poser des risques non négligeables en matière de sécurité. WordPress a depuis réduit ce qu’elle affiche, sans supprimer cet accès : voici comment le restreindre.

Explication du problème

Pour voir ce que votre site expose, ouvrez une fenêtre de navigation privée, où vous n’êtes pas connecté, et rendez-vous à l’adresse example.com/wp-json/wp/v2/users en remplaçant example.com par votre nom de domaine. Si vos permaliens sont réglés sur « Simple », utilisez plutôt example.com/?rest_route=/wp/v2/users.

Cette liste ne contient pas tous les comptes, mais seulement ceux qui ont publié au moins un contenu d’un type affiché dans l’API REST, comme les articles et les pages : WordPress 4.7.1 a resserré cette règle, qui s’appliquait auparavant à tous les types de contenus publics. C’est toujours le cas avec WordPress 7.1. Pour chacun de ces auteurs, l’API indique notamment son ID, son nom public, l’adresse de sa page d’auteur et son slug. L’identifiant de connexion et l’adresse e-mail n’y figurent pas, mais le slug est créé par défaut à partir de l’identifiant de connexion : il le reprend souvent tel quel.

La liste ainsi obtenue fournit donc des identifiants probables, qui pourraient être utilisés lors d’attaques sur votre formulaire de connexion. Même si vous disposez de protections additionnelles en limitant par exemple le nombre de tentatives, cela va nécessairement ralentir votre serveur.

Ce même slug apparaît aussi dans l’adresse de vos pages d’auteur, que l’API REST soit restreinte ou non. Pour qu’il ne révèle plus votre identifiant de connexion, modifiez-le, par exemple avec WP-CLI : wp user update 2 --user_nicename=nouveau-slug, où 2 est l’ID du compte. L’extension Edit Author Slug le permet aussi depuis l’administration, mais elle n’a plus été mise à jour depuis mai 2025.

Bloquer l’accès aux utilisateurs anonymes

Ne désactivez pas complètement l’API REST : la documentation officielle de l’API REST le déconseille, car une partie de l’administration de WordPress en dépend. Il reste deux niveaux de blocage pour les visiteurs non connectés : masquer seulement les routes des utilisateurs, ce qui règle le problème décrit plus haut, ou réserver toute l’API aux utilisateurs connectés.

Avec une extension

Si vous utilisez Wordfence, vérifiez simplement que son option Empêcher la découverte d’identifiants via les analyses « /?author=N », l’API oEmbed, l’API REST de WordPress et les plans de site XML de WordPress est cochée : elle l’est par défaut. Vous la trouverez dans Wordfence > Pare-feu, lien Toutes les options du pare-feu, section Protection anti force brute. Seuls les éditeurs et les administrateurs connectés peuvent alors obtenir la liste des utilisateurs. Le reste de l’API REST demeure accessible : Wordfence ne désactive pas l’API, et n’a pas besoin de le faire pour masquer vos identifiants.

D’autres extensions de sécurité proposent un réglage comparable : Kadence Security, anciennement iThemes Security, avec le réglage API REST de son module Ajustements WordPress à passer sur Accès restreint, ou SecuPress avec l’option Interdire l’énumération des comptes de son module Comptes & Connexion, qui rend aussi vos pages d’auteur inaccessibles.

Pour réserver toute l’API REST aux seuls utilisateurs connectés, il existe aussi une extension gratuite intitulée Disable REST API. Il suffit de l’installer puis de l’activer ; sa page de réglages permet ensuite d’autoriser certaines routes, rôle par rôle. Attention toutefois : elle n’a plus été mise à jour depuis septembre 2023 et n’a été testée que jusqu’à WordPress 6.3. Je vous conseille plutôt l’une des deux méthodes par code ci-dessous.

Si vous l’utilisez déjà, vérifiez qu’elle fonctionne correctement en ouvrant de nouveau l’URL mentionnée ci-dessus dans une fenêtre de navigation privée : la liste des utilisateurs n’est plus accessible, comme en témoigne ce message :

{"code":"rest_cannot_access","message":"DRA: Only authenticated users can access the REST API.","data":{"status":401}}

Par code : masquer seulement la liste des utilisateurs

C’est la méthode que je recommande : elle retire les routes /wp/v2/users de l’API pour les visiteurs non connectés, sans rien changer pour vos utilisateurs connectés ni pour le reste de l’API. Ajoutez ce code dans un mu-plugin plutôt que dans le fichier functions.php de votre thème : il restera actif si vous changez de thème.

/**
 * Hides the /wp/v2/users REST API routes from visitors who are not logged in.
 */
function wpc_hide_rest_users( $endpoints ) {
	if ( ! is_array( $endpoints ) || is_user_logged_in() ) {
		return $endpoints;
	}

	foreach ( array_keys( $endpoints ) as $route ) {
		if ( str_starts_with( $route, '/wp/v2/users' ) ) {
			unset( $endpoints[ $route ] );
		}
	}

	return $endpoints;
}
add_filter( 'rest_endpoints', 'wpc_hide_rest_users' );

Un visiteur anonyme qui demande la liste des utilisateurs, ou la fiche de l’un d’eux, reçoit désormais une erreur 404 :

{"code":"rest_no_route","message":"Aucune route correspondante \u00e0 l\u2019URL et \u00e0 la m\u00e9thode de requ\u00eate n\u2019a \u00e9t\u00e9 trouv\u00e9e.","data":{"status":404}}

Les requêtes authentifiées y ont toujours accès : l’éditeur de blocs peut toujours proposer le choix de l’auteur d’un article, et une application connectée avec un mot de passe d’application obtient toujours la liste. Ne vous étonnez pas, en revanche, de recevoir cette erreur 404 en ouvrant l’adresse dans votre navigateur alors que vous êtes connecté : sans jeton de sécurité (nonce), WordPress traite la requête comme anonyme.

Par code : réserver l’API REST aux utilisateurs connectés

Pour aller plus loin, comme le fait Disable REST API, le filtre rest_authentication_errors permet de refuser toute requête anonyme à l’API REST. Ce code reprend celui que propose la documentation officielle de l’API REST :

/**
 * Requires authentication for every REST API request.
 */
function wpc_rest_require_auth( $result ) {
	// A previous authentication check already succeeded or failed: keep its result.
	if ( true === $result || is_wp_error( $result ) ) {
		return $result;
	}

	if ( ! is_user_logged_in() ) {
		return new WP_Error(
			'rest_not_logged_in',
			__( 'You are not currently logged in.', 'wpchannel' ),
			array( 'status' => 401 )
		);
	}

	return $result;
}
add_filter( 'rest_authentication_errors', 'wpc_rest_require_auth' );

Les visiteurs anonymes reçoivent alors une erreur 401 avec le message « You are not currently logged in. », quelle que soit la route demandée. L’éditeur de blocs continue de fonctionner, puisque vous y êtes connecté, tout comme les applications qui s’authentifient avec un mot de passe d’application. En revanche, tout ce qui interroge l’API REST pour le compte de vos visiteurs cesse de fonctionner, par exemple l’envoi des formulaires de Contact Form 7 ou l’intégration de vos articles sur d’autres sites WordPress, qui passe par l’API oEmbed. Testez vos formulaires et vos pages en navigation privée après l’avoir mis en place, et préférez la méthode précédente au moindre doute.

Ce type de durcissement se vérifie à chaque version de WordPress : déléguez ce suivi à mon offre de maintenance préventive WordPress.

Autre précaution simple : masquer le numéro de version de WordPress.