HTTP ne garde par nature aucun souvenir d’une requête à l’autre : sans mécanisme complémentaire, un serveur ne saurait pas que la personne qui charge la page 2 est la même que celle qui a chargé la page 1. Le cookie comble ce manque : le serveur envoie un en-tête Set-Cookie, le navigateur le stocke, puis le renvoie automatiquement à chaque requête suivante vers ce domaine.
Les cookies dans WordPress
WordPress pose plusieurs cookies après connexion (wordpress_logged_in_..., wordpress_sec_...) pour maintenir la session d’un administrateur, ainsi qu’un cookie de commentaire si l’internaute coche « se souvenir de moi ». Les extensions e-commerce comme WooCommerce en ajoutent d’autres pour suivre le panier. Depuis le RGPD, un site doit informer et souvent recueillir un consentement avant de déposer les cookies non strictement nécessaires, d’où les bandeaux de consentement.
Exemple
Set-Cookie: wordpress_logged_in_abc123=user%7C...; path=/; HttpOnlyL’attribut HttpOnly empêche JavaScript de lire ce cookie, une protection utile contre certaines attaques XSS.
Pièges fréquents
- Confondre cookie et session : le cookie ne fait souvent que transporter un identifiant, les données elles-mêmes restent stockées côté serveur.
- Un cache de page trop agressif qui sert la même page HTML à tous les visiteurs, y compris à un utilisateur connecté, casse la personnalisation liée aux cookies : d’où la nécessité d’exclure les pages avec cookie de connexion du cache.
- Oublier que certains navigateurs bloquent par défaut les cookies tiers, ce qui peut casser des widgets intégrés depuis un autre domaine.