La REST API de WordPress est une interface puissante qui permet aux applications externes, thèmes et extensions d'interagir avec les données de votre site. Par défaut, WordPress expose un certain nombre de points de terminaison publics que n'importe qui peut interroger sans authentification. Bien que cela soit utile pour les configurations headless et les intégrations tierces, cela ouvre aussi la porte à des fuites d'informations, en particulier autour des données utilisateur.
Ce que la REST API de WordPress expose par défaut
Lorsque la REST API est entièrement accessible, plusieurs points de terminaison renvoient des données que la plupart des propriétaires de sites préféreraient garder privées. Les plus couramment exploités incluent :
/wp-json/wp/v2/users: renvoie une liste de tous les utilisateurs ayant publié au moins un article, y compris leur nom d'utilisateur, nom d'affichage, ID utilisateur, URL d'avatar et lien d'archive d'auteur./wp-json/wp/v2/users/1: renvoie des informations détaillées sur un utilisateur spécifique par ID. Les attaquants commencent souvent par l'ID 1 car c'est généralement le compte administrateur./wp-json/wp/v2/posts: liste les articles publiés avec les informations sur l'auteur./wp-json/wp/v2/pages: liste toutes les pages publiées, ce qui peut révéler la structure interne du site./wp-json/: le point de terminaison racine lui-même révèle toutes les routes enregistrées, donnant aux attaquants une feuille de route des capacités de votre site et des extensions installées.
Le point de terminaison /wp/v2/users est la plus grande préoccupation pour la plupart des sites. Les attaquants l'utilisent pour l'énumération des utilisateurs, collectant des noms d'utilisateur valides qu'ils alimentent ensuite dans des attaques par force brute sur la connexion. Même si vous utilisez des mots de passe forts, exposer les noms d'utilisateur supprime une couche de défense.
Pourquoi vous ne devriez pas désactiver complètement la REST API
Il peut être tentant de bloquer entièrement la REST API, mais le faire cassera plusieurs fonctionnalités essentielles de WordPress. L'éditeur de blocs Gutenberg dépend fortement des appels REST API pour charger les données de blocs, sauvegarder le contenu et gérer les médias. Si vous désactivez complètement l'API, Gutenberg ne se chargera pas et vous ne pourrez pas modifier les articles ou pages.
Au-delà de Gutenberg, de nombreuses extensions populaires reposent sur la REST API pour leur fonctionnement :
- Contact Form 7 : utilise des points de terminaison REST API pour la gestion de la soumission de formulaires dans les versions récentes.
- WooCommerce : repose sur des routes REST API pour les opérations du panier, le traitement du paiement et l'interface d'administration.
- Yoast SEO : utilise des appels REST API pour ses fonctionnalités de metabox et d'analyse de contenu dans l'éditeur.
- Jetpack : nécessite l'accès à la REST API pour sa connexion aux services WordPress.com.
L'approche correcte est la restriction sélective : bloquer l'accès public aux points de terminaison sensibles tout en gardant l'API disponible pour les utilisateurs authentifiés et la zone d'administration WordPress.
Restreindre la REST API aux utilisateurs connectés uniquement
La méthode la plus efficace consiste à exiger une authentification pour toutes les requêtes REST API. Ajoutez ce code au fichier functions.php de votre thème ou, mieux encore, à une extension personnalisée spécifique au site :
add_filter('rest_authentication_errors', function($result) {
// Si une vérification d'authentification précédente a déjà réussi ou échoué, la respecter
if (true === $result || is_wp_error($result)) {
return $result;
}
// Bloquer les requêtes non authentifiées
if (!is_user_logged_in()) {
return new WP_Error(
'rest_not_logged_in',
'You are not currently logged in.',
array('status' => 401)
);
}
return $result;
});Cette approche bloque tout accès à la REST API pour les visiteurs non connectés. Gutenberg, WooCommerce et autres extensions continuent de fonctionner normalement car leurs requêtes proviennent de sessions d'administration authentifiées. Les visiteurs essayant d'accéder à /wp-json/wp/v2/users recevront une erreur 401 au lieu de données utilisateur.
Une chose à garder à l'esprit : si votre site utilise un frontend headless ou si vous avez une fonctionnalité publique qui récupère des données via la REST API (par exemple, une recherche en direct alimentée par la REST API), cette méthode cassera cette fonctionnalité. Dans ces cas, l'approche sélective ci-dessous est mieux adaptée.
Désactiver sélectivement uniquement le point de terminaison des utilisateurs
Si vous souhaitez garder la REST API accessible pour un usage public mais empêcher spécifiquement l'énumération des utilisateurs, vous pouvez supprimer uniquement les points de terminaison des utilisateurs :
add_filter('rest_endpoints', function($endpoints) {
// Supprimer le point de terminaison de la liste des utilisateurs
if (isset($endpoints['/wp/v2/users'])) {
unset($endpoints['/wp/v2/users']);
}
// Supprimer le point de terminaison utilisateur unique
if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
unset($endpoints['/wp/v2/users/(?P[\d]+)']);
}
return $endpoints;
}); Cela laisse toutes les autres routes REST API fonctionnelles tout en bloquant spécifiquement le vecteur d'énumération des utilisateurs. C'est un bon compromis pour les sites qui ont besoin d'un accès REST API public pour la recherche, les requêtes de contenu ou d'autres fonctionnalités, mais qui veulent protéger les données utilisateur.
Supprimer le lien de découverte de la REST API du HTML
WordPress génère une balise <link rel="https://api.w.org/"> dans l'en-tête HTML et un en-tête Link dans les réponses HTTP. Ceux-ci indiquent aux outils automatisés où trouver la REST API. Bien que la suppression de ces balises ne désactive pas réellement l'API (les points de terminaison répondent toujours à leurs URL habituelles), elle réduit la découvrabilité :
// Supprimer le lien REST API de l'en-tête HTML
remove_action('wp_head', 'rest_output_link_wp_head');
// Supprimer le lien REST API des réponses XML-RPC
remove_action('xmlrpc_rpc_methods', 'rest_output_link_wp_head');
// Supprimer l'en-tête Link des réponses HTTP
remove_action('template_redirect', 'rest_output_link_header', 11);Cette étape est mieux utilisée en complément de l'une des méthodes de restriction ci-dessus, et non seule. Supprimer la balise lien sans restreindre les points de terminaison réels est de la sécurité par l'obscurité, qui offre une protection réelle minimale.
Utiliser une extension pour gérer l'accès à la REST API
Si vous préférez ne pas ajouter de code personnalisé, plusieurs extensions fournissent une interface utilisateur pour gérer l'accès à la REST API :
- Disable WP REST API : bloque tout accès à la REST API pour les requêtes non authentifiées avec un simple bouton. Aucune configuration nécessaire au-delà de l'activation de l'extension.
- WP REST API Controller : vous donne un contrôle granulaire sur les points de terminaison qui sont publics et ceux qui nécessitent une authentification, vous permettant d'autoriser certaines routes tout en en bloquant d'autres.
L'approche par extension est plus simple à gérer mais ajoute une dépendance. Si l'extension est désactivée ou supprimée lors d'une mise à jour, votre REST API redeviendra entièrement publique. L'approche basée sur le code est plus fiable pour une protection à long terme.
Tester vos restrictions de la REST API
Après avoir appliqué vos changements, vérifiez qu'ils fonctionnent correctement. Ouvrez une fenêtre de navigateur en navigation privée (afin de ne pas être connecté) et essayez d'accéder à ces URL sur votre site :
https://votresite.com/wp-json/wp/v2/usershttps://votresite.com/wp-json/wp/v2/users/1https://votresite.com/wp-json/
Si votre restriction fonctionne, ces URL devraient renvoyer une erreur 401 ou une réponse vide au lieu de données utilisateur. Connectez-vous ensuite à votre admin WordPress et confirmez que l'éditeur Gutenberg, vos formulaires et toute fonctionnalité WooCommerce fonctionnent toujours comme prévu.
Vérifier avec InspectWP
Après avoir mis en oeuvre vos changements, lancez un nouveau scan InspectWP sur votre site. La section Sécurité de votre rapport montrera si la REST API est accessible publiquement et si le point de terminaison des utilisateurs renvoie des données. Si la restriction fonctionne correctement, InspectWP rapportera l'API comme non accessible ou le point de terminaison utilisateur comme restreint.