Sessions et cookies : comment les sécuriser ?
En bref
Une session est le lien qui maintient un utilisateur connecté entre deux pages. Elle repose sur un identifiant stocké dans un cookie. Pour la sécuriser, ce cookie doit porter les attributs Secure, HttpOnly et SameSite, l'identifiant doit être renouvelé à chaque connexion, la session doit expirer après une durée limitée et pouvoir être fermée côté serveur.
Quand vous vous connectez à un espace client, le site ne redemande pas votre mot de passe à chaque page. Il conserve le lien grâce à une session, identifiée par un jeton déposé dans votre navigateur sous forme de cookie. Ce jeton vaut donc autant qu'un mot de passe : celui qui le récupère devient vous, sans avoir à s'authentifier.
Comment fonctionne une session
Un cookie est un petit fichier que le site demande au navigateur de conserver et de renvoyer à chaque requête. Pour une session, il contient un identifiant aléatoire, tandis que les informations réelles restent sur le serveur. Trois risques principaux pèsent sur ce mécanisme :
- l'interception du jeton lorsqu'il circule sans chiffrement ;
- sa lecture par un script malveillant introduit dans une page du site ;
- son utilisation à l'insu de l'utilisateur, quand un autre site déclenche une action sur le vôtre alors que la personne est encore connectée.
Les attributs à positionner sur les cookies
| Attribut | Effet |
|---|---|
Secure | Le cookie n'est transmis que sur une connexion chiffrée. Indispensable, et à combiner avec HTTPS sur la totalité du site. |
HttpOnly | Le cookie devient invisible pour les scripts de la page, ce qui limite fortement son vol en cas de faille d'affichage. |
SameSite | Le navigateur n'envoie plus le cookie lors de requêtes déclenchées depuis un autre site, ce qui coupe une catégorie entière d'abus. |
| Portée et durée | Restreindre le cookie au domaine et au chemin nécessaires, fixer une expiration plutôt que le laisser valable indéfiniment. |
Le cycle de vie de la session
- À la connexion : générer un nouvel identifiant de session. Conserver celui qui existait avant l'authentification permettrait à un tiers de le connaître à l'avance.
- Pendant la session : lier l'identifiant au compte côté serveur, et revérifier les droits à chaque action sensible plutôt qu'une seule fois à l'entrée.
- Après inactivité : fermer automatiquement la session. La durée dépend du contexte : quelques dizaines de minutes pour une interface d'administration, davantage pour un usage courant.
- À la déconnexion : invalider la session sur le serveur, pas seulement supprimer le cookie dans le navigateur.
- Au changement de mot de passe : fermer toutes les sessions ouvertes, y compris sur les autres appareils.
Les actions sensibles méritent une confirmation
Pour un changement d'adresse e-mail, de mot de passe ou de coordonnées bancaires, demandez une nouvelle preuve d'identité, même si la personne est déjà connectée. C'est la contre-mesure la plus simple face à un jeton détourné. Les formulaires qui modifient des données doivent par ailleurs comporter un jeton anti-rejeu, une valeur unique vérifiée par le serveur, pour s'assurer que la demande vient bien de votre propre site.
Cookies de session et cookies de mesure : ne pas confondre
Les cookies strictement nécessaires au fonctionnement, dont ceux de connexion, ne relèvent pas du même régime que les cookies de mesure d'audience ou de publicité, qui appellent un consentement. Cette distinction, détaillée dans notre article sur le bandeau cookies, est juridique et non technique : elle ne dispense d'aucune des précautions ci-dessus.
Ces réglages se vérifient rapidement et se corrigent dans la configuration de l'application. NexSecure les contrôle dans le cadre de la maintenance de votre site.
Questions fréquentes
Combien de temps doit durer une session ?
Il n'existe pas de durée universelle. Plus l'accès donne de pouvoir, plus l'expiration doit être courte : une interface d'administration se ferme après quelques dizaines de minutes d'inactivité, un espace de consultation peut rester ouvert plus longtemps.
Faut-il proposer une case « rester connecté » ?
C'est possible si elle repose sur un jeton distinct, révocable, à durée limitée, et si les actions sensibles redemandent une authentification. Cette option ne doit pas être proposée pour les comptes d'administration.
Que se passe-t-il si un jeton de session est volé ?
Le tiers accède au compte sans mot de passe, jusqu'à expiration de la session. D'où l'intérêt d'une durée limitée, d'une liste des sessions actives consultable par l'utilisateur et d'une fermeture immédiate lors d'un changement de mot de passe.
Le stockage local du navigateur est-il une alternative ?
Il est accessible aux scripts de la page, donc plus exposé qu'un cookie protégé par HttpOnly. Pour un jeton d'authentification, le cookie correctement configuré reste la solution la plus prudente.
Sources
Service lié
Articles liés
Rédigé par l'équipe NexSecure. Responsable de la publication : Yohann Toumine. Dernière mise à jour le 11 septembre 2026.
Une question sur votre situation ? Parler de votre projet