Se connecter à l’espace d’administration de WordPress ne transmet le mot de passe qu’une seule fois, au moment de la soumission du formulaire. Toutes les requêtes suivantes, pendant toute la durée de la session, s’appuient sur un cookie déposé dans le navigateur. Comprendre précisément ce que contient ce cookie, et ce qu’un vol de cookie permet réellement de faire, aide à évaluer correctement le risque et à configurer les bonnes protections.
Cet article se concentre sur le fonctionnement du cookie de session lui-même — sa structure, sa validation et les attributs qui le protègent — sans revenir sur les nonces, qui répondent à un besoin différent et complémentaire au sein du même mécanisme d’authentification.
Structure du cookie wordpress_logged_in
Après une connexion réussie, WordPress dépose un cookie nommé wordpress_logged_in_[hash], dont la valeur combine plusieurs éléments concaténés : le nom d’utilisateur, une date d’expiration, un jeton de session et une signature calculée à partir des clés secrètes du site (LOGGED_IN_KEY et LOGGED_IN_SALT) :
utilisateur|expiration|jeton|hmacLe mot de passe lui-même n’apparaît jamais dans ce cookie, ni sous une forme quelconque. C’est précisément ce qui distingue un vol de cookie d’un vol de mot de passe : un attaquant en possession du cookie obtient une session active, mais n’apprend rien qui lui permette de créer une nouvelle session après son expiration sans voler un nouveau cookie valide.
La vérification côté serveur
À chaque requête, la fonction interne wp_validate_auth_cookie() reconstruit la signature attendue à partir des éléments du cookie et des clés secrètes du site, puis la compare à celle fournie. Le jeton de session, quant à lui, est comparé à une liste de jetons valides stockée dans les métadonnées de l’utilisateur, gérée par la classe WP_Session_Tokens : cette liste permet, par exemple, de révoquer une session précise sans affecter les autres appareils connectés au même compte.
C’est ce mécanisme qui rend possible la fonctionnalité « Déconnecter tous les autres appareils » présente sur l’écran de profil utilisateur : elle invalide tous les jetons de session sauf celui de la session courante, sans nécessiter de changer le mot de passe ni les clés du site.
Les attributs qui protègent le cookie en transit et en stockage
Deux attributs de cookie, standards du protocole HTTP et non spécifiques à WordPress, réduisent significativement les moyens disponibles pour un attaquant cherchant à intercepter ou lire ce cookie :
- HttpOnly : empêche tout accès au cookie depuis du JavaScript exécuté dans la page, ce qui neutralise une grande partie de l’intérêt d’une faille XSS pour voler une session — le script injecté ne peut simplement pas lire la valeur du cookie.
- Secure : garantit que le cookie n’est transmis que sur une connexion chiffrée HTTPS, empêchant son interception en clair sur un réseau non sécurisé (Wi-Fi public, par exemple).
WordPress applique HttpOnly par défaut sur ses cookies d’authentification. L’attribut Secure dépend en revanche de la configuration du site : il n’est correctement appliqué que si WordPress détecte une connexion HTTPS active au moment de la génération du cookie, ce qui suppose un site entièrement servi en HTTPS, sans contenu mixte.
SameSite : limiter l’envoi automatique du cookie
L’attribut SameSite, largement adopté par les navigateurs modernes, contrôle si un cookie est envoyé lors d’une requête initiée depuis un autre site. Positionné à Lax (le comportement par défaut dans la plupart des navigateurs récents), il limite déjà une partie des scénarios de falsification de requête intersite, en complément — jamais en remplacement — de la protection par nonce propre à WordPress.
Ce qu’un cookie volé permet, et ce qu’il ne permet pas
Un cookie de session volé ouvre une session active, pas un accès permanent : il expire, il peut être révoqué, et il ne révèle jamais le mot de passe du compte.
Un attaquant en possession d’un cookie valide peut agir avec les privilèges du compte concerné jusqu’à l’expiration du cookie ou sa révocation explicite. Il ne peut pas, à partir de ce seul cookie, déduire le mot de passe du compte, ni se reconnecter après une déconnexion explicite ou une rotation des clés du site, qui invalide immédiatement tous les cookies émis jusque-là.
En résumé
Le cookie d’authentification WordPress encode une session vérifiable par signature, jamais le mot de passe lui-même. HttpOnly, Secure et SameSite forment trois lignes de défense complémentaires contre son interception ou son exploitation, chacune réduisant un scénario d’attaque distinct sans se substituer aux autres.
