Set-Cookie (Sécurité des cookies)

Comprendre les cookies et Set-Cookie

Un cookie est une petite information qu’un site demande au navigateur de conserver.

Les cookies peuvent avoir de nombreux usages : maintenir une session ouverte, mémoriser une préférence, conserver le contenu d’un panier ou reconnaître un utilisateur entre plusieurs pages.

Tous les cookies ne servent donc pas à la publicité ou au suivi. Certains sont indispensables au fonctionnement normal d’un site ou d’une application web.

Comment sont-ils créés ?

Le serveur peut demander au navigateur d’enregistrer un cookie grâce à l’en-tête HTTP :

Le navigateur enregistre alors cette information et peut la renvoyer automatiquement au serveur lors de requêtes suivantes.

C’est notamment ce mécanisme qui permet au serveur de reconnaître une session déjà ouverte lorsque l’utilisateur passe d’une page à une autre.

Protéger un cookie

Certains cookies peuvent être sensibles, notamment lorsqu’ils permettent au serveur de reconnaître un utilisateur déjà authentifié.

Si un cookie de session est récupéré ou utilisé par une personne non autorisée, celle-ci peut parfois détourner la session et agir comme si elle était déjà connectée au compte.

Plusieurs attributs permettent donc de limiter les situations dans lesquelles un cookie peut être envoyé ou accessible.

Exemple d’un cookie protégé

Secure

L’attribut Secure indique au navigateur que le cookie doit être transmis uniquement via une connexion HTTPS sécurisée.

Cela permet d’éviter qu’un cookie sensible soit envoyé sur une connexion HTTP non chiffrée, où il pourrait être davantage exposé.

HttpOnly

L’attribut HttpOnly empêche les scripts JavaScript classiques de la page d’accéder directement au cookie.

Cette protection est particulièrement importante pour les cookies de session : elle peut limiter les conséquences de certaines attaques XSS (Cross-Site Scripting) cherchant à voler un cookie depuis le navigateur.

SameSite

L’attribut SameSite contrôle dans quelles situations le navigateur peut envoyer un cookie lorsque la navigation implique plusieurs sites.

Il contribue notamment à limiter certaines attaques dans lesquelles un site malveillant tente de provoquer une action sur un autre site en utilisant la session déjà ouverte de l’utilisateur.

Contrôler la durée et la portée d’un cookie

Protéger un cookie ne consiste pas seulement à utiliser Secure, HttpOnly et SameSite.

Il faut également limiter la durée pendant laquelle il reste valide et les endroits du site où il peut être utilisé.

Durée de vie

Les attributs Max-Age et Expires permettent de déterminer combien de temps un cookie peut être conservé.

Plus un cookie sensible reste valide longtemps, plus la période pendant laquelle il pourrait être détourné est importante.

Sa durée de vie doit donc être limitée au temps réellement nécessaire.

Domain et Path

Un cookie peut également être limité à certains domaines ou à certaines parties d’un site.

Domain détermine les domaines auxquels le cookie peut s’appliquer, tandis que Path permet de restreindre son utilisation à une partie particulière du site.

Le principe est simple : un cookie ne devrait être disponible que là où il est réellement nécessaire. Limiter sa portée permet de réduire son exposition inutile au reste de l’application.

Bonnes pratiques et limites

Bonnes pratiques

• Utiliser Secure pour les cookies sensibles afin qu’ils soient transmis uniquement via HTTPS.
• Utiliser HttpOnly lorsqu’un cookie n’a aucune raison d’être accessible depuis JavaScript.
• Définir explicitement une valeur SameSite adaptée à l’utilisation du cookie.
• Limiter la durée de vie des cookies sensibles au strict nécessaire.
• Limiter leur portée aux domaines et chemins qui en ont réellement besoin.
• Appliquer des protections renforcées aux cookies utilisés pour l’authentification et les sessions utilisateur.

Un cookie de session ne contient normalement pas le mot de passe

Un site correctement conçu ne stocke normalement pas le mot de passe de l’utilisateur directement dans un cookie.

Un cookie de session contient plutôt un identifiant ou une valeur permettant au serveur de reconnaître une session déjà authentifiée.

Cette valeur reste néanmoins extrêmement sensible. Si un attaquant parvient à la récupérer et que les protections du site ne l’en empêchent pas, il peut parfois utiliser cette session sans connaître le mot de passe de l’utilisateur.

Ce que ces protections ne remplacent pas

Les attributs Secure, HttpOnly et SameSite constituent des protections essentielles pour les cookies sensibles, mais ils ne suffisent pas à sécuriser une session à eux seuls.

Ils ne remplacent notamment pas :

• l’utilisation systématique de HTTPS ;
• la prévention et la correction des vulnérabilités XSS ;
• la protection contre les requêtes non autorisées ;
• une gestion correcte des sessions et de leur expiration ;
• la sécurité générale du site et de son code.

Les cookies sensibles doivent donc être protégés dès leur création et pendant toute leur durée de vie. Une mauvaise configuration peut exposer directement une session utilisateur et permettre la compromission d’un compte.