Supprimer le cookie de session dans votre navigateur vous déconnecte-t-il côté serveur ?

Cette question sépare les ingénieurs qui comprennent où vit l'état de session de ceux qui croient que le cookie est la session. Se tromper conduit à des déconnexions cassées qui laissent des identifiants valides actifs.

Pourquoi la réponse populaire est fausse

Un cookie de session n'est qu'un identifiant porteur — généralement un ID de session opaque ou un jeton signé — que votre navigateur présente à chaque requête. Le supprimer de votre navigateur signifie que vous cessez de l'envoyer. Cela n'envoie aucun message au serveur ; le serveur ignore même que vous l'avez effacé. Pour une session classique côté serveur, l'enregistrement correspondant dans le magasin de sessions (mémoire, Redis, base de données) est toujours là et toujours valide. Pour un JWT, c'est pire : le jeton est autonome et cryptographiquement valide jusqu'à son expiration, sans aucune vérification serveur par défaut. Donc si une copie de ce cookie ou jeton a fuité — capturée sur un réseau compromis, volée du stockage local par XSS, ou tirée d'un journal de proxy — l'attaquant peut le rejouer longtemps après votre « déconnexion ».

Le bon modèle mental

Le cookie est un pointeur ; l'autorité vit sur le serveur. La déconnexion doit donc agir sur le serveur :

• Sessions avec état : supprimez l'enregistrement ou marquez-le invalide dans le magasin, pour que la prochaine requête avec cet ID soit rejetée. Puis effacez aussi le cookie client par propreté.
• JWT sans état : on ne peut pas vraiment supprimer un jeton signé, donc utilisez des TTL courts avec un modèle de jeton de rafraîchissement, et maintenez une liste de révocation (ou faites tourner les clés de signature) pour tuer les jetons plus tôt.

Pourquoi ça compte en pratique

C'est exactement pourquoi les fonctions « se déconnecter de tous les appareils » et de révocation existent — elles invalident l'état côté serveur pour qu'un identifiant volé meure. Fermer le navigateur n'aide pas non plus ; les serveurs n'expirent pas les sessions à la chute d'une socket, et les cookies persistants survivent à un redémarrage. La réponse prête pour l'entretien : supprimer le cookie est un geste côté client ; seule l'invalidation côté serveur termine vraiment une session.