Qu'est-ce que l'API REST de WordPress ?

L'API REST de WordPress est une interface intégrée qui permet aux applications externes, aux frontends basés sur JavaScript, aux applications mobiles et aux services tiers de communiquer avec votre site WordPress en utilisant des requêtes HTTP standard et des données JSON. Elle a été intégrée au cœur de WordPress dans la version 4.7 (décembre 2016) et est depuis devenue la colonne vertébrale du développement WordPress moderne, alimentant tout, de l'éditeur de blocs Gutenberg aux architectures WordPress headless.

Avant l'existence de l'API REST, le seul moyen programmatique d'interagir avec WordPress depuis l'extérieur était via XML-RPC, un protocole plus ancien et beaucoup plus limité. L'API REST a remplacé cette approche par quelque chose de bien plus flexible, mais elle a également introduit de nouvelles considérations de sécurité que tout propriétaire de site WordPress devrait comprendre.

Points de terminaison par défaut et ce qu'ils exposent

L'API REST se trouve à /wp-json/wp/v2/ sur chaque installation WordPress. Par défaut, elle expose une large gamme de points de terminaison :

• /wp-json/wp/v2/posts : retourne tous les articles publiés avec leur contenu complet, les ID d'auteur, les catégories, les étiquettes et les références d'image mise en avant.
• /wp-json/wp/v2/pages : identique aux articles mais pour les pages statiques.
• /wp-json/wp/v2/users : liste tous les utilisateurs ayant publié au moins un article. C'est le point de terminaison par défaut le plus sensible en matière de sécurité.
• /wp-json/wp/v2/categories et /wp-json/wp/v2/tags : retournent les termes de taxonomie avec descriptions et nombre d'articles.
• /wp-json/wp/v2/comments : liste les commentaires publics, y compris les noms des commentateurs et parfois les adresses e-mail si le site est mal configuré.
• /wp-json/wp/v2/media : liste les fichiers multimédias téléversés avec leurs URL, dimensions et métadonnées.
• /wp-json/wp/v2/search : fournit un point de terminaison de recherche qui reflète la recherche intégrée du site.
• /wp-json/ (la racine) : retourne un index complet de tous les espaces de noms et routes API enregistrés, révélant ainsi chaque extension qui enregistre ses propres points de terminaison API.

Les extensions ajoutent fréquemment leurs propres espaces de noms. WooCommerce ajoute /wp-json/wc/v3/, Yoast SEO ajoute des points de terminaison sous son espace de noms, et les extensions de formulaires de contact peuvent exposer des points de terminaison de soumission. L'index racine de l'API révèle tout cela, donnant à un attaquant une image claire des extensions installées.

Le risque d'énumération des utilisateurs

Le point de terminaison /wp-json/wp/v2/users est le problème de sécurité le plus discuté concernant l'API REST. Par défaut, n'importe qui peut visiter ce point de terminaison et obtenir une réponse JSON listant tous les utilisateurs ayant créé du contenu. Chaque entrée d'utilisateur inclut son nom d'utilisateur (le champ slug), le nom affiché, l'ID utilisateur, l'URL de l'avatar et un lien vers ses archives d'auteur.

Pourquoi est-ce important ? Parce que les noms d'utilisateur représentent la moitié de l'équation de connexion. Si un attaquant sait que votre compte administrateur utilise le nom d'utilisateur sarah_admin, il n'a plus qu'à deviner (ou forcer par brute force) le mot de passe. Sans l'API REST, trouver des noms d'utilisateur demandait plus d'efforts, comme deviner des URL d'archives d'auteur telles que /?author=1. L'API REST distribue ces informations gratuitement dans un format structuré et lisible par machine.

Ce n'est pas une préoccupation théorique. Des bots automatisés explorent régulièrement /wp-json/wp/v2/users sur les sites WordPress pour constituer des listes de cibles pour des attaques par bourrage d'identifiants et par force brute. Si votre site a un utilisateur nommé admin, ce compte sera le premier visé.

Méthodes d'authentification pour l'API REST

Les requêtes non authentifiées vers l'API REST ne retournent que les données publiquement disponibles (articles publiés, profils utilisateurs publics, etc.). Pour créer, mettre à jour ou supprimer du contenu via l'API, vous avez besoin d'une authentification. WordPress prend en charge plusieurs méthodes :

• Authentification par cookie : c'est ce qu'utilise l'éditeur Gutenberg. Lorsque vous êtes connecté à WordPress, votre navigateur envoie des cookies de session avec chaque requête API. Une valeur nonce empêche la falsification de requête inter-sites. Cette méthode ne fonctionne que dans le contexte du navigateur.
• Mots de passe d'application : introduits dans WordPress 5.6, cette fonctionnalité vous permet de générer des mots de passe uniques pour chaque application nécessitant un accès à l'API. Chaque mot de passe d'application est lié à un compte utilisateur spécifique. Vous pouvez les révoquer individuellement sans changer votre mot de passe principal. Ils sont envoyés via HTTP Basic Auth et ne fonctionnent qu'en HTTPS.
• JWT (JSON Web Tokens) : non intégré au cœur de WordPress, mais disponible via des extensions comme "JWT Authentication for WP REST API". JWT est populaire pour les configurations WordPress headless où une application frontend doit authentifier les utilisateurs et effectuer des appels API en leur nom.
• OAuth : également disponible via des extensions. OAuth est la méthode préférée lorsque des applications tierces doivent accéder à l'API de votre site au nom de vos utilisateurs, car elle évite de partager directement les mots de passe.

Quand vous avez réellement besoin de l'API REST

L'API REST n'est pas une fonctionnalité optionnelle que vous pouvez désactiver à la légère. Elle est profondément intégrée au cœur de WordPress et de nombreuses extensions en dépendent :

• Éditeur de blocs Gutenberg : toute l'expérience d'édition repose sur l'API REST. Chaque fois que vous créez, enregistrez ou prévisualisez un article dans l'éditeur de blocs, il communique avec l'API REST. La désactiver vous obligerait à revenir à l'éditeur Classique.
• WordPress headless : si vous utilisez WordPress comme backend de gestion de contenu avec un frontend séparé construit en React, Vue, Next.js ou Nuxt, l'API REST (ou son nouvel équivalent, WPGraphQL) est la manière dont le frontend récupère le contenu.
• Applications mobiles : l'application mobile officielle WordPress communique avec votre site via l'API REST. De nombreuses applications personnalisées pour sites d'adhésion, plateformes d'apprentissage ou médias l'utilisent également.
• Fonctionnalités d'extensions : de nombreuses extensions modernes s'appuient sur l'API REST pour leurs interfaces d'administration. Les extensions qui utilisent React ou Vue pour leurs pages de paramètres effectuent des appels API en arrière-plan. WooCommerce, Jetpack, Yoast SEO et des dizaines d'autres ne fonctionneraient pas sans elle.
• Intégrations tierces : Zapier, IFTTT et des outils d'automatisation similaires peuvent interagir avec votre site WordPress via l'API REST, permettant des workflows comme la création automatique d'articles à partir de soumissions de formulaires ou la synchronisation de contenu entre plateformes.

Durcissement de la sécurité sans casser les choses

La bonne approche n'est pas de désactiver entièrement l'API REST, mais de restreindre les parties qui exposent des informations sensibles. Voici des étapes pratiques :

• Restreindre le point de terminaison utilisateurs : exigez une authentification pour /wp/v2/users. Plusieurs extensions de sécurité offrent cela avec un simple interrupteur. Vous pouvez également ajouter un extrait de code à functions.php de votre thème ou à une extension personnalisée qui se branche sur rest_authentication_errors pour bloquer l'accès non authentifié à des points de terminaison spécifiques.
• Supprimer le lien API REST du HTML : WordPress génère une balise <link rel="https://api.w.org/"> dans l'en-tête HTML, annonçant l'URL de l'API. Supprimer cette balise ne désactive pas l'API, mais cesse d'annoncer son emplacement aux scanners automatisés.
• Désactiver XML-RPC en parallèle : si vous sécurisez l'API REST, désactivez également l'ancienne interface XML-RPC (/xmlrpc.php), qui présente son propre lot de vulnérabilités par force brute et DDoS.
• Utiliser une extension pare-feu : des extensions comme Wordfence, Sucuri ou iThemes Security peuvent limiter l'accès à l'API par adresse IP, bloquer les bots malveillants connus et ajouter une limitation de taux pour empêcher l'abus automatisé.
• Supprimer les points de terminaison d'extensions inutilisés : si une extension enregistre des routes API dont vous n'avez pas besoin, vous pouvez utiliser le filtre rest_endpoints pour les supprimer. Cela réduit votre surface d'attaque et empêche également la fuite d'informations sur les extensions installées.

Ce que vérifie InspectWP

InspectWP vérifie si l'API REST est publiquement accessible en recherchant la balise <link rel="https://api.w.org/"> dans le code source HTML de votre site. Il teste également si le point de terminaison /wp-json/wp/v2/users retourne des données utilisateur sans authentification, ce qui indiquerait un risque d'énumération d'utilisateurs. Si la balise de lien API est présente, InspectWP rapporte l'URL de l'API REST découverte. Si des données utilisateur sont exposées, cela est signalé comme un problème de sécurité avec une recommandation de restreindre ce point de terminaison aux seules requêtes authentifiées.