L’essor des intégrations WordPress et des agents rend les interfaces publiques plus sollicitées. Protégez les données et les ressources endpoint par endpoint : couper toute l’API peut casser l’éditeur, une application ou une boutique.
1. Distinguer accès public et autorisation
Inventoriez les routes utilisées par le site, les extensions et les automatisations. Notez méthode, données renvoyées, rôle attendu et caractère public ou privé. Un article publié peut être public ; une adresse client, un brouillon ou une clé ne doit pas apparaître dans une réponse anonyme.
Sur une route personnalisée, vérifiez les capacités de l’utilisateur, puis son droit sur l’objet demandé. Être connecté ne suffit pas. Ce fragment remplace uniquement le contrôle de permission d’une route de consultation/modification d’article existante :
'permission_callback' => function ($request) { $id = absint($request['id']); return $id > 0 && current_user_can('edit_post', $id);},Validez aussi les paramètres et limitez les champs renvoyés. Une route volontairement publique demande quand même une validation des entrées et un contrôle de coût.
2. Tester les identités et limiter les abus
Pour une intégration externe, créez un utilisateur dédié aux capacités minimales et un Application Password distinct, via HTTPS. Le mot de passe d’application ne constitue pas à lui seul une restriction fine aux routes : les droits du compte restent déterminants. Stockez-le dans les credentials de l’intégration et révoquez-le quand elle disparaît.
Ce test demande le mot de passe de manière interactive, sans l’écrire dans la commande :
BASE="https://example.com/wp-json/wp/v2"curl --fail --user integration --get \ "$BASE/users/me" --data-urlencode "context=edit"Comparez ensuite les routes sensibles en anonyme, avec un compte limité et avec l’identité autorisée, sur des données de test. Les cookies et nonces utilisés dans l’éditeur répondent à un autre contexte ; un nonce n’accorde pas une capacité supplémentaire.
Dans Cloudflare, commencez par une règle de rate limiting ciblant le chemin réellement coûteux et sa méthode. Vérifiez aussi les requêtes utilisant le paramètre rest_route. Adaptez seuil et fenêtre aux journaux observés et aux fonctions disponibles dans votre formule. Une simple règle WAF ne fournit pas automatiquement un compteur de requêtes.
3. Déployer avec une surveillance exploitable
Testez sous le seuil, au-delà du seuil puis après expiration, uniquement dans votre périmètre autorisé. Évitez un challenge navigateur sur une intégration machine. Prévoyez une exception étroite pour un service authentifié, jamais pour tout trafic portant un User-Agent facile à imiter.
Journalisez route, méthode, statut, durée et volume ; masquez Authorization, cookies et corps sensibles. Recherchez rafales, erreurs répétées et lectures inhabituelles. Un accès direct à l’origine peut contourner un contrôle placé uniquement devant elle.
Erreurs fréquentes
Bloquer toute la REST API, confondre CORS avec authentification ou croire que masquer les utilisateurs protège les données privées.
FAQ et vérification finale
Peut-on empêcher tout scraping public ? Non. Réduisez les abus sans confondre contenu public et secret.
Le WAF remplace-t-il les permissions ? Non : l’application doit toujours autoriser chaque action.
Validez éditeur, médias, formulaires et intégrations, ainsi que le refus d’accès aux objets privés et la révocation d’un credential de test.
Sources : WordPress, endpoints, WordPress, authentification, Cloudflare.