Sécuriser les API WordPress sans casser le site
L’API REST WordPress est utile : elle alimente l’éditeur, les applications mobiles, certains formulaires, WooCommerce, des outils métiers ou des intégrations externes. Le réflexe de tout bloquer est rarement la bonne réponse. Le vrai objectif est de laisser fonctionner les routes légitimes, tout en limitant ce qu’un visiteur anonyme, un compte compromis ou un script automatisé peut faire.
Commencer par inventorier les routes exposées
Avant de sécuriser, il faut savoir ce qui est exposé. Sur un site WordPress, l’API est généralement accessible via /wp-json/. Certaines routes sont publiques par conception, par exemple pour lire des articles. D’autres ne devraient répondre qu’à des utilisateurs authentifiés ou à une application autorisée.
La priorité est d’identifier les routes ajoutées par les plugins. Beaucoup d’incidents viennent de modules qui exposent un endpoint trop permissif : formulaire, import/export, statistiques, constructeur de page, espace membre, paiement ou livraison.
Les risques les plus fréquents
- Contrôle d’accès cassé : l’API renvoie ou modifie des données sans vérifier correctement les capacités WordPress.
- Authentification faible : jeton réutilisable, clé exposée, nonce mal compris, compte avec trop de droits.
- Énumération : l’API révèle des utilisateurs, slugs internes, extensions ou contenus privés.
- Entrées non validées : paramètres envoyés à une requête SQL, à une action système ou à un rendu HTML.
- Absence de limitation : une route coûteuse peut être appelée des milliers de fois.
Utiliser les capacités WordPress, pas seulement is_user_logged_in()
Une route sensible ne doit pas se contenter de vérifier qu’un utilisateur est connecté. Il faut contrôler la capacité précise : edit_posts, manage_options, permission WooCommerce dédiée, ou capacité personnalisée. C’est ce qui permet d’éviter qu’un auteur, un abonné ou un compte compromis obtienne plus que ce qu’il devrait.
Pour les actions depuis l’administration, les nonces WordPress ont un rôle utile contre les requêtes forgées. Pour une intégration serveur à serveur, préférez une authentification adaptée : application passwords, OAuth selon le contexte, clé d’API stockée hors dépôt et rotation possible.
Réduire l’exposition sans casser les usages publics
Il est possible de masquer certaines informations aux visiteurs anonymes : détails utilisateurs, routes internes, messages d’erreur trop bavards. En revanche, bloquer brutalement toute l’API peut casser Gutenberg, WooCommerce ou des plugins. La bonne méthode consiste à filtrer route par route, puis à tester le front, l’admin et les intégrations.
Ajoutez aussi des limites de débit sur les endpoints sensibles : login, recherche, formulaires, export, panier, paiement. Une protection WAF peut aider, mais elle ne remplace pas les contrôles dans le code.
Checklist de durcissement
- Cartographier toutes les routes
/wp-json/. - Vérifier les permissions avec
current_user_can(). - Limiter les données retournées aux champs nécessaires.
- Valider et typer tous les paramètres.
- Éviter les messages d’erreur qui révèlent chemins, requêtes ou secrets.
- Journaliser les appels anormaux et mettre une limite de fréquence.
- Mettre à jour les plugins qui ajoutent des endpoints publics.
Une API WordPress sécurisée n’est pas invisible : elle est prévisible. Chaque route a une raison d’exister, un niveau d’accès clair, une validation stricte et un comportement mesurable en cas d’abus.
