Comment vérifier la sécurité des cookies : Secure, HttpOnly, SameSite et préfixes de cookies

Lorsqu'un internaute se connecte à votre site, le serveur remet en général à son navigateur un cookie de session. Dès lors, quiconque détient ce cookie est cet utilisateur. Les attributs du cookie déterminent quand le navigateur l'envoie, sur quelles connexions, et si les scripts de la page peuvent le lire. Bien les régler coûte une ligne de configuration ; mal les régler peut transformer un petit bug en prise de contrôle d'un compte.

Les attributs qui comptent

Secure

Secure demande au navigateur de n'envoyer le cookie qu'en HTTPS. Sans lui, le cookie peut transiter par une requête HTTP en clair (par exemple lorsque quelqu'un saisit votre domaine sans https://, avant que la redirection n'ait lieu), où n'importe qui sur le même réseau peut le lire. Sur un site en HTTPS, tous les cookies devraient être Secure.

HttpOnly

HttpOnly masque le cookie à JavaScript (document.cookie). Si un attaquant parvient à injecter un script dans votre page, il ne peut pas se contenter de lire un cookie de session pour l'envoyer ailleurs. Utilisez-le sur les cookies de session et d'authentification. Les cookies que votre propre code front-end doit lire, comme un jeton CSRF que certains frameworks exposent volontairement à JavaScript, ne peuvent pas être HttpOnly : c'est normal.

SameSite

SameSite détermine si le cookie est envoyé lorsqu'une requête provient d'un autre site :

• SameSite=Strict : envoyé uniquement avec les requêtes émises depuis votre propre site. C'est le réglage le plus sûr, mais un visiteur qui suit un lien reçu par e-mail arrive sur votre site en paraissant déconnecté.
• SameSite=Lax : envoyé lors des navigations de premier niveau, comme un clic sur un lien, mais pas avec les envois de formulaires, les images ou les cadres intersites. Une bonne valeur par défaut pour les cookies de session.
• SameSite=None : envoyé dans tous les contextes intersites, ce qui est nécessaire aux widgets intégrés et à certains parcours d'authentification unique. Il doit être associé à Secure, faute de quoi les navigateurs rejettent le cookie.

Les navigateurs fondés sur Chromium traitent un cookie dépourvu d'attribut SameSite comme s'il valait Lax, mais tous les navigateurs ne se comportent pas de la même façon : définissez-le donc explicitement.

Domain et Path

Omettez Domain et le cookie est limité à l'hôte (host-only) : il n'est envoyé qu'à l'hôte exact qui l'a déposé. Définir Domain=example.com le partage avec tous les sous-domaines, y compris ceux, oubliés, qui tournent sur un autre hébergement peut-être moins sûr. N'élargissez sa portée que si vous devez vraiment partager une connexion entre sous-domaines.

Expires et Max-Age

Sans Expires ni Max-Age, un cookie est censé durer le temps de la session du navigateur, même si les navigateurs qui restaurent les sessions peuvent le conserver plus longtemps. Pour les connexions persistantes, choisissez une durée de vie proportionnée au risque, et veillez à ce que le serveur fasse lui aussi expirer les sessions de son côté.

Les préfixes de cookies : __Host- et __Secure-

Les préfixes de nom de cookie permettent au navigateur de faire respecter des règles à votre place. Un cookie dont le nom commence par __Secure- n'est accepté que s'il porte l'attribut Secure et a été déposé en HTTPS. Un cookie commençant par __Host- est soumis à des règles plus strictes : il doit être Secure, déposé en HTTPS, avoir Path=/ et aucun attribut Domain. Il est ainsi verrouillé sur un seul hôte, de sorte qu'un sous-domaine compromis ou négligent ne peut pas l'écraser.

Pour un cookie de session qui n'a pas besoin d'être partagé entre sous-domaines, __Host- est l'option la plus robuste qui existe : Set-Cookie: __Host-session=…; Secure; HttpOnly; SameSite=Lax; Path=/.

Comment vérifier vos cookies

1. Dans le navigateur. Ouvrez les outils de développement, allez dans Application (Chrome, Edge) ou Stockage (Firefox), puis Cookies, et sélectionnez votre site. Le tableau affiche pour chaque cookie les colonnes Domain, Path, Expires, HttpOnly, Secure et SameSite.
2. Dans la réponse brute. Dans l'onglet Réseau, cliquez sur la requête du document et lisez les en-têtes de réponse Set-Cookie. Vous voyez ainsi exactement ce que le serveur a envoyé, y compris les attributs que le navigateur a pu rejeter.
3. Après connexion. De nombreux sites ne déposent leurs cookies importants qu'après l'authentification ou à la création d'un panier : vérifiez donc de nouveau sur ces pages.
4. Avec un outil de vérification. L'outil gratuit de test de sécurité de Rudra lit les en-têtes Set-Cookie de la réponse de la page elle-même et signale les cookies sans Secure en HTTPS, les cookies apparentés à des cookies de session sans HttpOnly, les SameSite=None sans Secure, les cookies sans SameSite et les cookies dont la portée s'étend à un domaine parent.

Deux limites du contrôle automatique méritent d'être connues. Il juge qu'un cookie « ressemble à un cookie de session » d'après son nom (ceux qui contiennent des éléments comme sess, sid, token ou auth) et signale donc ces constats avec un niveau de confiance moyen : vérifiez ce que le cookie contient réellement. Et il ne voit que les cookies déposés par cette seule réponse, pas ceux déposés plus tard par JavaScript, par d'autres pages, après connexion ou par des tiers. Les valeurs des cookies ne sont jamais lues ni stockées.

Comment définir les attributs des cookies sur les plateformes courantes

• Sessions PHP : dans php.ini, définissez session.cookie_secure = 1, session.cookie_httponly = 1 et session.cookie_samesite = "Lax" (PHP 7.3 et versions ultérieures), ou passez les mêmes options à session_set_cookie_params().
• Django : SESSION_COOKIE_SECURE = True et CSRF_COOKIE_SECURE = True. SESSION_COOKIE_HTTPONLY et SESSION_COOKIE_SAMESITE = "Lax" sont déjà les valeurs par défaut.
• Express (Node.js) : res.cookie("sid", value, { secure: true, httpOnly: true, sameSite: "lax" }), ou les options cookie de express-session. Derrière un proxy, activez trust proxy pour qu'Express sache que la connexion est en HTTPS.
• WordPress : les cookies de connexion du cœur sont HttpOnly, et marqués Secure lorsque le site fonctionne en HTTPS. Ceux des extensions varient ; vérifiez-les dans les outils de développement et interrogez les auteurs de l'extension s'il leur manque des attributs.
• Le reverse proxy en dernier recours : la directive proxy_cookie_flags de nginx (1.19.3 et versions ultérieures) peut ajouter secure, httponly et samesite aux cookies d'une application que vous ne pouvez pas modifier.

Les erreurs courantes

• Marquer les cookies Secure en production mais ne tester qu'en HTTP en local, puis désactiver l'attribut « temporairement ».
• Définir SameSite=None sans Secure : les navigateurs écartent alors le cookie, et une connexion ou une intégration cesse de fonctionner.
• Étendre les cookies de session au domaine parent « au cas où ».
• Stocker les jetons de session dans localStorage, où n'importe quel script injecté peut les lire ; les cookies HttpOnly sont plus sûrs.
• Placer des données personnelles dans la valeur des cookies. Un cookie doit contenir des identifiants, pas des informations.

Les cookies ne sont qu'une pièce de l'ensemble. Pour les en-têtes, HTTPS et les limites des tests passifs, lisez comment vérifier la sécurité d'un site web.