Authentification REST par cookie et nonce
Définition : L’authentification REST par cookie repose sur la session WordPress du navigateur et sur une nonce dédiée aux requêtes API. Elle sert aux actions réalisées par un utilisateur déjà connecté au site.
Comprendre et utiliser
À quoi sert cette notion ?
Elle permet au JavaScript de l’administration ou d’un espace privé d’appeler des endpoints en conservant l’identité de la session WordPress.
Fonctionnement technique
Le client envoie les cookies de session et généralement l’en-tête X-WP-Nonce contenant une nonce créée pour l’action wp_rest. Le serveur valide ce contexte avant les vérifications de capacité.
Dans quel contexte l’utiliser ?
Un tableau d’édition ATOOLPHA modifie un brouillon via la REST API depuis l’interface d’un utilisateur connecté et autorisé.
Étude de cas : application professionnelle
Un utilisateur connecté au tableau de bord peut employer les cookies WordPress pour appeler une route REST, mais sa requête d’écriture doit aussi comporter une nonce appropriée. Le serveur applique ensuite la permission liée à la ressource. Pour un atelier de test, vérifier successivement lecture publique, écriture sans nonce, écriture avec nonce valide et écriture avec un compte insuffisamment autorisé. Les résultats doivent être différents. Ce parcours démontre qu’une nonce ne crée pas de privilèges et que la sécurité ne repose jamais sur la seule présence d’un jeton transmis par JavaScript.
Exemple technique commenté
Cet extrait est destiné à un fichier PHP chargé par WordPress, idéalement dans un plugin local de test. Il ne doit pas être placé dans l'éditeur de contenu. Avant exécution, vérifier que les objets et variables mentionnés existent dans le contexte et que les permissions nécessaires sont définies.
<?php
// À produire côté serveur pour un utilisateur connecté.
$nonce = wp_create_nonce( 'wp_rest' );
// La transmettre au JavaScript autorisé, puis envoyer
// la valeur dans l’en-tête X-WP-Nonce.Décryptage du code et résultat attendu
La nonce illustre la protection liée à la session. Elle ne permet pas de se connecter à distance à elle seule et doit rester associée aux vérifications de capacité.
Exercice guidé pour vérifier la notion
Effectuer une lecture publique, puis tenter un appel d’écriture de test avec et sans nonce depuis une session réellement autorisée.
Précautions et limites
Ne pas exposer la nonce en clair dans un cache partagé. Une nonce n’est pas un mot de passe et ne remplace pas current_user_can().
À ne pas confondre
Le cookie identifie la session ; la nonce participe à la protection de la requête ; la permission_callback décide l’accès à la ressource.
Diagnostic avancé
Un 403 après expiration de session ou cache incorrect peut provenir d’une nonce invalide ; vérifier sa génération et la politique de cache.
Choix d’architecture et déploiement
Pour les clients externes sans session navigateur, préférer des mécanismes d’authentification prévus à cet effet, comme les mots de passe d’application sur HTTPS.
