Gestion de session : cookies, expiration et déconnexion à tester

Une fois l'utilisateur connecté, l'ID de session équivaut temporairement à la méthode d'authentification la plus forte employée par l'application, qu'il s'agisse d'un mot de passe, d'un code à usage unique, d'un certificat client, d'une carte à puce ou d'une empreinte digitale. Si un attaquant peut deviner, capturer ou imposer cet ID, il devient l'utilisateur, et le formulaire de connexion n'entre jamais en jeu. Tester les sessions revient donc à tester l'ID, le cookie qui le transporte, et ce que fait le serveur avec cet ID à la connexion, après une période d'inactivité et à la déconnexion.

Cette checklist s'appuie sur la OWASP Session Management Cheat Sheet et sur la RFC 6265, la spécification des cookies.

L'ID de session lui-même

Commencez par la façon dont l'ID est fabriqué. La cheat sheet exige au moins 64 bits d'entropie issus d'un générateur de nombres aléatoires cryptographiquement sûr. À cette taille, elle estime à environ 585 ans le temps nécessaire pour deviner un ID valide, en supposant 10 000 tentatives par seconde et 100 000 sessions valides simultanées. Si vous générez vos propres ID au lieu d'utiliser ceux du framework, elle recommande au moins 128 bits et une valeur unique pour chaque session.

Cherchez les parties fixes ou prévisibles. Un ID hexadécimal de 16 caractères dont la moitié est fixe n'offre que 32 bits d'entropie, ce qui est insuffisant. La valeur ne doit en outre rien signifier pour le client : ni identifiant d'utilisateur, ni rôle, ni e-mail à l'intérieur. Conservez cet état côté serveur.

Vérifiez aussi le nom. Des noms par défaut comme PHPSESSID, JSESSIONID, CFID/CFTOKEN et ASP.NET_SessionId indiquent à un attaquant quelle pile vous utilisez. La cheat sheet suggère un nom générique tel que id.

N'acceptez jamais l'ID dans une URL. Les ID transmis par URL fuient via les liens, les journaux, l'historique du navigateur, les favoris, l'en-tête Referer et les moteurs de recherche, et ils facilitent la fixation de session.

Si l'accès en lecture à votre magasin de sessions fait partie de votre modèle de menace, les jetons en clair constituent un risque. La cheat sheet décrit une conception en deux parties : le cookie transporte un identifiant et un secret de vérification, et le serveur stocke l'identifiant ainsi que le hash SHA-256 du secret, comparé en temps constant. L'identifiant seul n'est jamais accepté.

Attributs des cookies

La RFC 6265 définit les attributs suivants pour un en-tête Set-Cookie : Expires, Max-Age, Domain, Path, Secure et HttpOnly.

• Secure réserve le cookie aux connexions sécurisées. La RFC avertit qu'il n'offre aucune garantie d'intégrité face à un attaquant actif sur le réseau : ne le considérez donc pas comme une protection contre un tel attaquant.
• HttpOnly doit figurer sur chaque cookie de session. Confirmez la présence de l'attribut dans les outils de développement du navigateur.
• Domain et Path définissent la portée. Gardez les deux aussi restreints que l'application le permet.
• Expires et Max-Age indiquent au navigateur combien de temps conserver le cookie. Ne vous en servez pas comme délai d'expiration de session.

Passez en revue le reste de vos en-têtes de réponse avec notre outil d'analyse des en-têtes de sécurité.

Connexion, expiration et déconnexion

Un ID de session que le navigateur détenait avant la connexion et conserve après est précisément ce sur quoi reposent les attaques par fixation. Émettez un nouvel ID lorsque l'utilisateur s'authentifie, afin que le précédent cesse d'être valide.

L'expiration demande deux limites. Un délai d'inactivité met fin aux sessions que personne n'utilise. Un délai absolu met fin aux sessions qui restent actives indéfiniment, ce qui limite la durée pendant laquelle un ID volé reste exploitable. Écrivez les valeurs noir sur blanc, choisissez-les plus courtes pour l'administration et les paiements, et appliquez-les côté serveur en vérifiant l'enregistrement de session stocké, et non la date d'expiration du cookie.

La déconnexion doit détruire la session côté serveur. Effacer le cookie dans le navigateur ne suffit pas, car l'identifiant est le justificatif d'accès : quiconque l'a copié auparavant peut encore l'envoyer. Après la déconnexion, l'ancien ID ne doit correspondre à rien. La cheat sheet contient également une section sur la mise en cache du contenu web et sur Clear-Site-Data, qui mérite d'être lue pour savoir ce que le navigateur conserve après la déconnexion.

Utilisez autant que possible la gestion de session native du framework. La cheat sheet précise que ces implémentations ont connu des vulnérabilités : utilisez donc la dernière version et passez en revue les paramètres par défaut.

Que tester

1. Capturez le cookie avant et après la connexion. La première requête doit effectivement positionner un cookie de session : vérifiez donc que before.txt n'est pas vide. Gardez les identifiants dans un fichier (creds.txt contenant user=test&pass=...) pour qu'ils restent hors de l'historique du shell. Les deux ID doivent être différents.

curl -i -c before.txt https://app.example/login curl -i -b before.txt -c after.txt -d @creds.txt https://app.example/login

1. Déconnectez-vous avec le cookie authentifié, puis rejouez l'ancienne valeur, prise dans la dernière colonne de after.txt. Elle doit être rejetée. Si la déconnexion se fait en POST, ajoutez -d '' à la première commande.

curl -i -b after.txt https://app.example/logout curl -i -b 'id=VALUE_FROM_AFTER_TXT' https://app.example/account

1. Connectez-vous, restez inactif au-delà du délai d'inactivité, puis envoyez une requête. Elle doit exiger une nouvelle authentification.
2. Maintenez une session active au-delà du délai absolu. Elle doit tout de même prendre fin.
3. Inspectez Set-Cookie dans la réponse de connexion : Secure, HttpOnly, ainsi qu'un Domain et un Path pas plus larges que nécessaire.
4. Collectez quelques centaines d'ID et comparez-les. Des segments fixes ou des valeurs séquentielles constituent des constats. Comparez le nom du cookie aux noms par défaut des frameworks cités plus haut.
5. Recherchez des ID de session dans les URL, au sein de l'application, des journaux et des liens.

Rapportez vos constats par rapport à l'OWASP ASVS en indiquant la version : v5.0.0-<chapter>.<section>.<requirement>. L'ASVS 5.0.0 a été publié le 30 mai 2025 et ses exigences sont disponibles au format CSV. Ajoutez à votre feuille de test une colonne contenant l'identifiant correspondant à chaque test, de sorte qu'un test échoué se lise comme un constat citant son exigence.

Par où commencer

1. Exécutez d'abord les tests 1 et 2 sur l'environnement de préproduction : la comparaison des ID avant et après la connexion, puis le rejeu après déconnexion.
2. Capturez l'en-tête Set-Cookie de votre cookie de session et corrigez les attributs manquants ou trop larges.
3. Vérifiez comment les ID sont générés. Si vous avez écrit votre propre générateur, passez à celui du framework, ou confirmez qu'il utilise une source aléatoire sûre avec au moins 128 bits.
4. Notez les délais d'inactivité et absolu, appliquez-les côté serveur, et ajoutez des tests qui échouent si quelqu'un les supprime.
5. Faites en sorte que la déconnexion supprime l'enregistrement de session côté serveur, et ajoutez les tests de rejeu à votre suite de non-régression.