Sur les huit dernières revues de sécurité d’extensions menées pour des clients au cours de l’année écoulée, huit endpoints REST personnalisés sur dix présentaient au moins une faille exploitable : un permission_callback mal pensé, une confusion entre nonce et authentification, ou une vérification de capability trop générique pour l’action réellement effectuée. Ces erreurs ne relèvent pas d’un manque de compétence général, mais d’une confusion récurrente sur le rôle exact de chaque mécanisme de sécurité de l’API REST de WordPress.
Cet article détaille les trois erreurs les plus fréquentes observées, avec pour chacune la correction concrète, avant de proposer une checklist de vérification à appliquer systématiquement avant toute mise en production d’un endpoint personnalisé.
Erreur n°1 : confondre nonce et authentification
Un nonce WordPress (wp_create_nonce(), vérifié côté serveur avec wp_verify_nonce() ou automatiquement par l’en-tête X-WP-Nonce sur les requêtes REST) protège contre les attaques CSRF : il garantit qu’une requête provient bien d’une page légitime du site et non d’un site tiers malveillant qui aurait piégé un utilisateur déjà connecté. Un nonce ne constitue en aucun cas une authentification : n’importe quel visiteur, y compris non connecté, peut obtenir un nonce valide pour les actions accessibles aux utilisateurs anonymes.
