Depuis l'intégration de l'éditeur Gutenberg, WordPress s'appuie en permanence sur sa REST API, accessible à l'adresse /wp-json/ de n'importe quel site. Ce point d'entrée, devenu indispensable au fonctionnement même du CMS, est aussi l'une des surfaces les plus régulièrement scrutées par les outils d'attaque automatisés.
À quoi sert réellement la REST API
La REST API permet à des applications externes, y compris l'éditeur de WordPress lui-même, de lire et d'écrire du contenu via des requêtes HTTP structurées plutôt que par l'interface d'administration classique. Elle alimente :
- L'éditeur Gutenberg, qui communique avec le serveur via cette API à chaque modification de contenu.
- Les applications mobiles officielles WordPress.
- De nombreuses intégrations tierces et sites « headless », où WordPress sert uniquement de back-office de contenu, affiché par une autre application via l'API.
La désactiver complètement casse donc des fonctionnalités centrales du CMS moderne, ce qui en fait une décision à prendre avec précaution, pas un réflexe de sécurité par défaut.
Pourquoi elle attire l'attention des attaquants
Deux problèmes reviennent régulièrement :
- L'énumération des utilisateurs : par défaut, l'endpoint /wp-json/wp/v2/users révèle les identifiants et noms d'affichage des comptes auteurs du site, une information précieuse pour préparer une attaque par force brute ciblée sur un identifiant précis plutôt qu'à l'aveugle.
- Les vulnérabilités ponctuelles : plusieurs failles de sécurité critiques découvertes dans le cœur de WordPress au fil des années ont transité précisément par des routes REST API mal validées, ce qui en a fait une cible d'étude privilégiée pour les chercheurs en sécurité comme pour les attaquants.
Comment la sécuriser sans la casser
- Restreignez l'accès à l'endpoint d'énumération des utilisateurs pour les visiteurs non authentifiés, via un plugin dédié ou un filtre personnalisé, plutôt que de couper toute la REST API.
- Maintenez le cœur de WordPress, les thèmes et les extensions à jour : la quasi-totalité des failles exploitées via la REST API concernent des versions obsolètes pour lesquelles un correctif existe déjà.
- Pour un site qui n'a aucun usage externe de l'API (pas d'application mobile, pas d'intégration tierce), certains plugins de sécurité permettent de restreindre son accès aux seuls utilisateurs authentifiés, tout en laissant les routes nécessaires à Gutenberg fonctionner pour les administrateurs connectés.
- Un pare-feu applicatif ou un service de surveillance comme SiteLock ajoute une couche de détection supplémentaire sur ce type de tentative.
Vérifier vous-même votre exposition
Avant d'appliquer une quelconque restriction, il est utile de vérifier concrètement ce que votre propre site expose aujourd'hui. Il suffit de visiter dans un navigateur, sans être connecté, l'adresse suivante de votre propre site : /wp-json/wp/v2/users. Si cette page affiche une liste de noms et d'identifiants numériques d'utilisateurs, cette information est accessible publiquement à n'importe quel visiteur, y compris aux outils automatisés de reconnaissance avant une attaque.
Ce test simple, à refaire après chaque changement de configuration de sécurité, permet de confirmer concrètement qu'une restriction mise en place fonctionne bien, plutôt que de supposer qu'elle est active sans l'avoir vérifié sur le site réel.
Pour les intégrations qui ont réellement besoin d'un accès programmatique à votre site, WordPress propose depuis la version 5.6 un mécanisme natif plus sûr que le partage d'un mot de passe classique : les mots de passe d'application (application passwords), générés individuellement pour chaque usage depuis le profil utilisateur, et révocables indépendamment les uns des autres sans affecter le mot de passe principal du compte ni les autres intégrations actives.
Peut-on désactiver complètement la REST API de WordPress ?
Techniquement oui, via certains plugins, mais cela casse l'éditeur Gutenberg et toute intégration qui en dépend. Pour la grande majorité des sites, restreindre des endpoints précis est une approche plus sûre que la désactivation complète.
L'énumération des utilisateurs est-elle vraiment dangereuse ?
Elle ne compromet rien en elle-même, mais elle facilite nettement une attaque par force brute en donnant à l'attaquant des identifiants réels à tester, plutôt que de devoir les deviner. C'est un facilitateur d'attaque, pas une faille à elle seule.
Garder son cœur WordPress et ses extensions à jour reste la mesure la plus efficace contre les vulnérabilités exploitées via ce type de point d'entrée. Le service SiteLock de VSP TECH surveille ce type de comportement suspect en continu sur votre hébergement WordPress, en complément d'une bonne hygiène de mise à jour.
