L'API REST de WordPress : ce que c'est, pourquoi elle est ouverte, comment la sécuriser

Une porte que la plupart des propriétaires de site ignorent

Quand la faille wp2shell a été publiée avec WordPress 7.0.2, un détail a surpris beaucoup de gens : l’attaque passait par une fonctionnalité active par défaut sur toutes les installations, sans qu’aucun plugin soit nécessaire.

Cette fonctionnalité, c’est l’API REST de WordPress. Si tu n’en as jamais entendu parler alors que tu as un site WordPress, c’est normal, et c’est exactement le sujet de cet article.

À quoi sert l’API REST

Une API, c’est une porte d’entrée par laquelle un programme parle à un autre programme. L’API REST de WordPress permet à des logiciels extérieurs de lire et d’écrire dans ton site sans passer par l’interface d’administration.

Concrètement, elle est utilisée par :

• l’éditeur de contenu de WordPress lui-même : quand tu écris un article et que tu vois « Enregistrement automatique », c’est l’API REST qui travaille ;
• l’application mobile WordPress ;
• de nombreux plugins, pour communiquer avec des services externes ;
• les sites découplés, où l’affichage est géré par une autre technologie qui vient chercher le contenu dans WordPress ;
• des intégrations avec un CRM, une newsletter, une caisse, un outil de statistiques.

Autrement dit : ce n’est pas un gadget, c’est une pièce centrale du fonctionnement moderne de WordPress. La désactiver entièrement casse des choses, à commencer par l’éditeur.

Pourquoi elle est ouverte par défaut

Depuis WordPress 4.7, l’API REST est active sur toutes les installations. Une partie de ses points d’entrée est accessible sans authentification, par conception : la liste publique des articles, par exemple, n’est pas plus secrète que la page qui les affiche.

Le point d’entrée impliqué dans wp2shell, /wp-json/batch/v1, existe dans le cœur depuis WordPress 5.6. Il sert à regrouper plusieurs requêtes en une seule, pour éviter de multiplier les allers-retours réseau.

La vulnérabilité ne venait pas du fait que cette route existe, mais d’une confusion dans la façon dont elle interprétait certaines requêtes, combinée à une injection SQL. C’est l’enchaînement des deux qui ouvrait la porte.

Voir ce que ton site expose

Tu peux regarder toi-même. Ouvre dans ton navigateur :

https://tonsite.fr/wp-json/

Tu obtiens un gros bloc de texte structuré qui liste les routes disponibles. C’est normal et ce n’est pas, en soi, une faille.

Deux adresses valent le coup d’œil :

https://tonsite.fr/wp-json/wp/v2/users

Celle-ci peut lister les comptes ayant publié du contenu. Elle ne révèle pas de mots de passe, mais elle donne des identifiants de connexion potentiels à qui veut tenter une attaque par force brute.

https://tonsite.fr/wp-json/wp/v2/posts

Celle-ci liste tes articles publiés. Rien de secret, mais utile pour comprendre ce qui sort.

Comment durcir sans rien casser

Voici les mesures classées de la plus sûre à la plus engageante.

1. Mettre à jour (la seule qui corrige vraiment cette faille)

Aucun durcissement de l’API ne remplace le correctif. Si tu es en 7.0.0, 7.0.1, ou en 6.9.0 à 6.9.4, passe en 7.0.2 ou 6.9.5. Tout le reste vient après.

2. Masquer la liste des comptes

Empêcher l’énumération des utilisateurs via l’API réduit la surface d’attaque sans rien casser dans la quasi-totalité des cas. La plupart des plugins de sécurité proposent cette option en une case à cocher.

C’est une mesure de confort défensif : elle ne bloque pas un attaquant déterminé, elle élimine le bruit automatisé.

3. Limiter le nombre de requêtes

Un pare-feu applicatif (WAF), au niveau de l’hébergement ou via un service en frontal, permet de plafonner le nombre de requêtes par adresse IP et par minute.

C’est probablement la mesure la plus rentable : elle protège l’API REST, mais aussi la page de connexion, les formulaires et le reste du site. Et elle agit avant que la requête n’atteigne WordPress.

4. Restreindre l’accès aux routes sensibles

Si ton site n’utilise pas les fonctionnalités de regroupement de requêtes, tu peux bloquer la route correspondante au niveau du serveur web. C’est efficace, mais il faut savoir ce qu’on fait : certains plugins l’utilisent en arrière-plan, et un blocage aveugle se traduit par des erreurs difficiles à diagnostiquer des semaines plus tard.

Si tu prends cette voie : teste sur une copie du site avant, et documente ce que tu as bloqué.

5. Ne pas désactiver l’API entièrement

On lit parfois le conseil de couper complètement l’API REST. C’est presque toujours une mauvaise idée sur un site moderne : tu casses l’éditeur, tu casses des plugins, et tu obtiens un site fragile pour un gain de sécurité faible.

Mieux vaut une API à jour et encadrée qu’une API désactivée à moitié qui laisse le site bancal.

Ce que cette faille nous apprend vraiment

Le point intéressant n’est pas que WordPress ait eu une faille. Tout logiciel massivement déployé en a, et le cœur de WordPress est plutôt bien surveillé : la vulnérabilité a été signalée par des chercheurs, corrigée, et publiée avec un correctif disponible immédiatement.

Le point intéressant, c’est que la surface d’attaque d’un site WordPress est plus large que ce que son propriétaire imagine. Tu vois des pages ; le serveur, lui, expose aussi des routes d’API, des points d’entrée de plugins, des fichiers de configuration, des tâches planifiées.

C’est précisément pour ça qu’un site professionnel a besoin d’un minimum de suivi : non pas parce que WordPress serait dangereux, mais parce qu’un système riche demande qu’on regarde ce qu’il expose.

En résumé

1. Mets à jour vers 7.0.2 ou 6.9.5. C’est la seule action qui corrige la faille.
2. Bloque l’énumération des comptes.
3. Mets un pare-feu avec limitation de débit devant ton site.
4. Ne coupe pas l’API REST en entier.
5. Fais le ménage dans tes plugins : chaque extension ajoute ses propres routes.

Si tu veux qu’on regarde ce que ton site expose actuellement et qu’on te dise en une page ce qui mérite d’être fermé, écris-nous.