WordPress a toujours eu une face publique et une face interne. L’API REST, située entre les deux, fait exactement ce pont. Elle permet aux thèmes, aux plugins, à des apps mobiles et à certains services d’automatisation de lire ou modifier des données. Mais c’est aussi une surface d’attaque, parce que beaucoup de choses passent par des URL, des verbes HTTP, des permissions, des cookies ou des jetons.
Quand on parle de protection site WordPress, le réflexe consiste souvent à “verrouiller wp-admin” ou à durcir le login. C’est utile. Pourtant, sur de nombreux sites, la véritable faille opérationnelle arrive côté REST, surtout quand l’API est exposée sans contrôle fin, quand des endpoints sont activés sans raison, ou quand l’authentification est mal gérée.
Je vais vous guider à travers une méthode pragmatique pour sécuriser l’API REST et les points d’accès associés, en tenant compte des réalités du terrain: compatibilités plugins, contraintes de maintenance, et effets secondaires possibles.
Pourquoi l’API REST devient un point névralgique
Une installation WordPress “classique” gère déjà des permissions, mais l’API REST change le rythme. Au lieu de ne voir que des formulaires d’administration et quelques actions utilisateur, vous exposez des mécanismes programmatiques.
Concrètement, les risques les plus courants ne sont pas toujours spectaculaires. Ce sont plutôt des détails qui finissent par coûter cher:
- des endpoints REST qui acceptent trop facilement des requêtes authentifiées, des rôles WordPress utilisés de manière trop permissive, des configurations CORS ou d’en-têtes qui facilitent des appels indésirables, des plugins qui augmentent l’exposition en ajoutant leurs propres routes, et, très souvent, un manque de contrôle sur qui peut parler à quoi.
Sur un site multi-auteurs que j’ai aidé à remettre d’aplomb, le problème n’était pas un “piratage direct”. Les journaux montraient des requêtes REST régulières, avec des patterns de bruteforce sur des actions sensibles liées aux contenus. Rien ne cassait immédiatement. Mais l’activité montait, la latence aussi, et certains endpoints répondaient avec des messages d’erreur trop informatifs. Ce mélange d’indices et de répétitions finit par ouvrir des portes.
L’enjeu, ce n’est pas seulement d’empêcher l’accès. C’est aussi de limiter le “bruit” côté logs, de réduire l’attaque en surface, et de rendre l’escalade plus difficile.
Comprendre ce que vous exposez réellement
Avant de couper, il faut savoir ce qu’il y a à couper. L’API REST de WordPress fonctionne via des routes, par exemple sous /wp-json/. Selon la configuration, le site répond à des endpoints publics, d’autres qui exigent une authentification, et d’autres encore qui ne sont accessibles qu’aux rôles autorisés.
La première étape utile, c’est de cartographier. Vous n’avez pas besoin d’une thèse, mais vous devez répondre à des questions simples:
- Quels endpoints sont réellement utilisés par vos applications ou par vos plugins ? Quels endpoints sont uniquement nécessaires en back-office ? Quels endpoints renvoient des données sensibles, même si ce n’est pas “secret” au sens strict ?
Dans beaucoup de cas, la cartographie montre une vérité embarrassante: le site a continué d’héberger des plugins dont les routes REST ne servent plus, mais restent actives.
Un test simple, sans casser le site
Vous pouvez inspecter l’index REST (souvent disponible à l’URL /wp-json/ ou via un fichier de découverte selon la version et la config). L’objectif n’est pas de faire un audit exhaustif au premier jour, mais de repérer les familles de routes et de distinguer ce qui est public de ce qui semble restreint.
Si vous avez une politique de changement stricte, faites ces tests en environnement de staging. J’ai déjà vu un blocage trop agressif de l’API REST casser l’éditeur de contenu ou certaines intégrations côté front. Le service a semblé “fonctionner” au début, puis une action a échoué sous un angle particulier: rechargement d’une image, mise à jour d’un statut, appel à un endpoint de sauvegarde.
Durcir l’accès: au-delà du “on bloque wp-admin”
Sécuriser l’API REST ne se limite pas à filtrer /wp-json/ au niveau serveur. Il faut penser en couches: authentification, autorisation, limitation et contrôle réseau. Les “points d’accès” ne sont pas uniquement des URLs, ce sont aussi des interfaces, des accès CDN, des règles WAF, des proxys, et parfois des paramètres de plugin.
Authentifier proprement, limiter ce qui peut être modifié
WordPress propose plusieurs mécanismes d’authentification selon vos besoins (cookies d’administration, application passwords, jetons selon plugins, etc.). Le bon choix dépend de votre usage réel.
- Si vous avez une app mobile ou un service externe, l’option la plus saine consiste à utiliser un mécanisme d’accès dédié, avec un principe de moindre privilège. Évitez les identifiants “admin” partagés, même “temporairement”. Si votre back-office est accessible via l’interface classique, gardez l’authentification centrée sur des sessions normales, plutôt que de multiplier des entrées REST qui acceptent des requêtes trop permissives.
Le piège, c’est l’illusion de sécurité: “l’endpoint est derrière une authentification”. Oui, mais laquelle ? Si la configuration fait que n’importe quel utilisateur authentifié peut appeler des actions sensibles, vous n’êtes pas vraiment protégé.
Autoriser au niveau des rôles, pas à l’aveugle
Dans WordPress, les capacités sont fondamentales. Pour l’API REST, l’idée correcte est simple: chaque route doit appliquer des contrôles d’autorisation cohérents. Les plugins tiers, eux, peuvent faire des choix discutables: ils laissent des endpoints accessibles à des rôles qui ne devraient pas y toucher, ou ils se reposent sur une logique “si connecté, alors tout va bien”.
Sur un site e-commerce avec des extensions marketing, j’ai vu des endpoints REST ajouter des actions qui correspondaient à des opérations internes, sans distinguer soigneusement un rôle “auteur” d’un rôle “éditeur”. Résultat, des utilisateurs avec des permissions limitées pouvaient déclencher des opérations qui ne leur étaient pas destinées. Ce n’était pas une fuite massive de données. Mais c’était une dérive d’autorisation.
La règle d’or: pour les endpoints modificateurs (création, suppression, mise à jour), la barre d’autorisation doit être plus haute que pour un simple affichage.
Filtrer l’exposition côté serveur (sans casser les fonctionnalités)
Le filtrage réseau est souvent la première barrière efficace. Selon votre environnement, vous pouvez agir via Nginx, Apache, un reverse proxy, un WAF ou même des règles CDN. L’objectif n’est pas de “tout bloquer”. L’objectif est de fermer ce qui n’est pas requis.
Je vous propose une logique en deux temps: d’abord, réduire; ensuite, mesurer.
Une approche pragmatique en checklist
Voici un jeu de contrôles que j’utilise pour cadrer une protection site WordPress autour de l’API REST, sans entrer dans une guerre de configuration:
- Identifier les endpoints REST réellement utilisés par vos clients (front, app, intégrations, plugins). Vérifier les rôles WordPress autorisés pour les actions modifiantes via REST. Limiter les origines et les verbes acceptés quand c’est possible (par ex. éviter que certains endpoints répondent à des méthodes non prévues). Ajouter un rate limiting sur les routes REST exposées au public. Surveiller les logs et les erreurs après chaque changement pendant au moins 48 heures.
Vous remarquerez que je n’inclus pas “couper l’API REST” à la première minute. Dans beaucoup de sites, ce serait trop brutal.
Contrôler le trafic: rate limiting et anti-abus
Les attaques contre l’API REST prennent rarement la forme d’un seul gros coup. Elles ressemblent plutôt à une rafale répétitive, avec variation de paramètres. Cela peut être du bruteforce, des tentatives d’exfiltration, ou des tests automatiques de endpoints.
Le rate limiting aide surtout à gagner du temps et à réduire l’impact. Il n’empêche pas tout, mais il diminue la pression.
Où appliquer la limitation ?
Appliquer la limitation “globale” sur /wp-json/ peut suffire, mais parfois c’est trop approximatif. Si vos utilisateurs utilisent des appels REST légitimes et sensibles à la latence, un rate limit trop agressif devient un problème. Dans ce cas, vous pouvez viser des catégories de routes ou des verbes.
Exemple pratique: si votre front lit des informations via REST, limiter strictement les requêtes GET sur un endpoint de lecture peut dégrader l’expérience. À l’inverse, limiter les requêtes POST sur des endpoints qui déclenchent des modifications est souvent plus raisonnable.
Je préfère une démarche où l’on commence modérée, puis on ajuste selon les journaux. Le bon chiffre dépend du trafic, et aussi de la manière dont vos clients se connectent (nombre d’utilisateurs, fréquence de polling, présence de caches).
Gérer l’authentification sans créer d’angles morts
L’authentification est le cœur, mais c’est aussi la zone où les effets secondaires apparaissent.
Cookies et CSRF: ne confondez pas le “ça marche” et le “c’est sûr”
Si votre API REST est consommée depuis le front avec des cookies, vous devez penser à la protection CSRF. WordPress dispose de mécanismes pour l’administration et pour certaines actions, mais selon la façon dont vous appelez l’API, et selon les plugins qui exposent des routes, il peut y avoir des écarts.
Symptôme typique: tout semble correct en test manuel, mais des actions sont déclenchées via des requêtes forgées sous certaines conditions. Dans ce cas, il ne s’agit pas seulement de “restreindre l’endpoint”, mais de garantir que la route valide les jetons attendus et applique une politique d’autorisation cohérente.
Application Passwords: utile, mais à encadrer
Les passwords d’application (quand ils sont utilisés) sont une option raisonnable pour des intégrations spécifiques. Le problème, c’est la dérive: des mots de passe créés pour un projet oublié, jamais révoqués, ou utilisés à la place d’un vrai compte technique.
Sur la maintenance d’un site qui fonctionnait depuis plusieurs années, on https://gardewp.fr/securite-wordpress/ a découvert que plusieurs application passwords avaient été générés à une époque où le plugin d’intégration changeait souvent. Les identifiants étaient stockés dans un gestionnaire de secrets. Problème, une intégration avait été remplacée sans supprimer l’ancien. Les clés restaient valides. La surface d’attaque restait donc vivante.
Le correctif a été simple: rotation et révocation, puis vérification que seuls les services actifs utilisaient les nouvelles identifiants. C’est une hygiène qui se voit peu, mais qui paie.
Jetons et intégrations tierces
Beaucoup de sites utilisent des plugins qui ajoutent des mécanismes d’accès. Tant que ces mécanismes sont conformes aux capacités WordPress et qu’ils ont une logique claire d’expiration et de rotation, c’est acceptable. Le danger, ce sont les plugins qui exposent des endpoints plus larges que nécessaire, ou qui acceptent des requêtes avec validation insuffisante.
La prudence que j’applique: si un plugin ajoute des routes REST “modifiantes”, j’essaie de vérifier quelles capacités sont requises et si la logique correspond à l’usage réel.
Personnaliser les points d’accès: éviter l’universalité
Vous ne sécurisez pas uniquement des URLs, vous sécurisez des points d’accès dans le sens infrastructure et exposition. Cela inclut:
- vos règles WAF ou CDN, la géographie ou les IP autorisées, l’accès admin et les routes d’API associées, et parfois la segmentation réseau (par exemple, admin accessible uniquement via VPN ou via un sous-domaine).
Réduire la surface avec une séparation
Une stratégie qui marche bien, surtout pour les équipes avec une stack front séparée, consiste à segmenter l’accès. Par exemple, vous pouvez limiter certaines routes REST à un sous-ensemble d’utilisateurs ou à des origines réseau spécifiques, tout en laissant les endpoints de lecture publics.
Cela demande de la discipline sur le front, parce qu’il faut que vos clients sachent où appeler, et avec quel contexte d’authentification. Mais le gain est réel: moins de choses exposées, moins de risques.
Voici une logique de décision que j’utilise, parce qu’elle force à choisir au lieu d’espérer que “ça ne sera pas attaqué”:
- Si le besoin est “lecture publique”, privilégier des endpoints de lecture et laisser le reste restreint. Si le besoin est “modification via un outil”, restreindre aux origines réseau de cet outil et appliquer les rôles. Si le besoin est “admin seulement”, envisager un accès admin plus strict et limiter les routes liées à l’édition. Si le besoin n’est plus réel, retirer le plugin ou désactiver les routes qu’il ajoute.
Cette approche évite le piège d’une configuration trop globale.
Désactiver ou bloquer: quand c’est pertinent, quand ça casse
La tentation est grande de “désactiver l’API REST” si elle n’est pas nécessaire. Parfois, c’est une excellente décision. Mais WordPress et l’écosystème plugin font que la réalité est souvent plus nuancée.
Avant de désactiver, je regarde généralement:
- si un plugin front dépend de l’API REST, si des fonctions de gestion (auto-publication, traduction, synchronisation) utilisent REST, et si des outils de monitoring ou de maintenance s’appuient dessus.
Dans un projet, désactiver REST a semblé fonctionner, puis l’éditeur a commencé à afficher des erreurs sur des actions liées aux médias. Le site restait “utilisable” au quotidien, mais la maintenance devenait pénible, avec des symptômes intermittents. On a dû reconfigurer, parce que REST était implicitement utilisé par un composant.
Quand désactiver est pertinent: quand vous êtes certain que rien de votre chaîne ne dépend des endpoints, et quand vous pouvez mesurer l’impact après mise en place. Si vous ne pouvez pas le mesurer, gardez une approche graduelle: filtrage sélectif, rate limiting, contrôle d’autorisations.
Durcissement de la configuration WordPress liée à REST
Certains réglages et pratiques WordPress réduisent le risque sans toucher à l’API elle-même.
Rôles et comptes techniques
Même si l’API REST est bien filtrée, si vous utilisez des comptes trop permissifs, vous créez un contournement “légitime”. Un utilisateur avec des capacités élevées peut appeler des endpoints. La sécurité se joue alors sur la réduction des privilèges et sur l’hygiène des comptes.
Je recommande d’utiliser des comptes techniques dédiés, limités au strict nécessaire, et de supprimer les comptes inutiles. Et côté maintenance, surveiller les changements de rôles, parce qu’un plugin peut modifier des permissions lors d’un réglage, parfois sans que l’équipe s’en rende compte.
Plugins: le vrai facteur d’écart
Les plugins sont souvent la cause d’une exposition REST plus large que prévu. Chaque plugin ajoute des routes, des hooks, parfois des capacités ou des paramètres de sécurité.
Une règle simple: moins de plugins actifs sur une instance de production, moins de routes REST inconnues. La réduction du nombre de plugins n’est pas seulement une question de performance, c’est aussi une réduction de surface.
J’ai déjà vu une situation où une intégration marketing nécessitait quelques endpoints REST, mais après une mise à jour elle ne les utilisait plus. Le plugin était resté actif. La route restait donc exposée, alors qu’elle n’était plus indispensable.
Mesurer, surveiller, itérer: la sécurité comme processus
On ne sécurise pas une API REST une fois pour toutes. On ajuste, on observe, on réagit.
Ce que vous cherchez dans les logs
Sans promettre des règles universelles, je regarde généralement:
- des patterns de requêtes répétitives, des tentatives sur des endpoints non utilisés, des erreurs qui indiquent des comportements de validation, et des pics qui correspondent à des changements (nouveau plugin, nouvelle version, nouvelle intégration).
Par exemple, si vous appliquez un rate limiting et que vos logs montrent que des erreurs 429 arrivent seulement sur une route précise, vous pouvez ajuster le seuil. Si vous voyez des erreurs 401 ou 403 répétées sur une route modifiante, c’est plutôt bon signe, cela indique que l’accès non autorisé est bloqué. Si vous voyez des 200 sur des actions sensibles déclenchées de façon inattendue, là, il faut réagir.
Déployer par étapes
La sécurité “d’un coup” échoue souvent parce qu’elle ne prend pas en compte l’usage réel. Les équipes qui réussissent déploient par étapes.
Un schéma assez efficace: commencer par la surveillance et la cartographie, appliquer ensuite le contrôle de flux (rate limiting), puis renforcer l’authentification et l’autorisation, enfin seulement envisager des restrictions plus strictes sur certains endpoints.
Cette méthode garde la possibilité de revenir en arrière rapidement, ce qui est crucial quand un plugin met du temps à remonter des dépendances cachées.
Exemple de scénario réaliste (et ce que j’aurais fait)
Imaginons un site WordPress avec:
- un front qui utilise REST pour charger des contenus filtrés, un plugin de traduction, et une intégration de newsletter via un endpoint custom.
En audit, vous constatez que plusieurs routes custom modifient des données et qu’elles sont autorisées à des rôles trop larges. Vous observez aussi des requêtes automatiques à cadence élevée sur /wp-json/, dont une partie n’a aucun pattern lié aux clients connus.
J’aurais procédé ainsi:
1) Cartographier les endpoints nécessaires, valider lesquels sont publics et lesquels sont modifiants. 2) Mettre un rate limiting modéré sur l’ensemble /wp-json/, puis affiner sur les verbes et sur les routes les plus touchées. 3) Ajuster les rôles autorisés pour les endpoints modifiants, en s’assurant que seules les capacités requises sont acceptées. 4) Réviser les plugins qui ajoutent des routes REST, et activer uniquement ce qui est nécessaire. 5) Surveiller pendant deux cycles de 24 heures après chaque changement, pour éviter les “surprises” liées à une dépendance qui ne s’active qu’à certaines heures ou à certains parcours.
C’est moins sexy que “je coupe tout”, mais c’est ce qui tient dans le temps.
Points d’attention spécifiques: CORS, verbes HTTP, et retours de statut
Il y a trois détails qui reviennent souvent dans les audits:
- CORS: s’il est mal configuré, il facilite des appels depuis des origines non prévues. Verb es HTTP: certaines routes acceptent des méthodes non nécessaires (ou répondent de manière trop tolérante). Retours de statut et messages: trop d’informations dans les erreurs peuvent donner des indices aux attaquants.
Je traite ces points comme des “accents”, pas comme des solutions seules. Un endpoint peut être bien autorisé et malgré tout permettre du probing via des réponses trop bavardes. L’inverse existe aussi: un endpoint répond de manière silencieuse mais autorise une action modifiante à trop de rôles. La sécurité doit être cohérente de bout en bout.
Checklist finale avant de durcir davantage
Je termine avec une liste courte, parce qu’au moment de toucher à l’accès, il faut être méthodique:
- Testez en staging tout changement lié à /wp-json/ ou aux règles WAF. Vérifiez l’impact sur vos fonctionnalités front et sur l’édition (médias, sauvegardes, statuts). Limitez l’exposition des endpoints modifiants, pas seulement l’accès global. Appliquez des seuils de rate limiting adaptés à votre trafic, puis ajustez après mesure. Révoquez les identifiants et jetons inutilisés, surtout les comptes d’intégration.
La sécurité de l’API REST n’est pas un mur. C’est un ensemble de décisions qui réduisent la probabilité d’une exploitation, et augmentent le coût pour un attaquant. Quand l’équipe adopte cette logique, la protection site WordPress devient beaucoup plus stable, et les incidents deviennent plus rares, moins bruyants, et plus simples à traiter.