Cookies HttpOnly, Secure et SameSite

Ce que chaque attribut empêche

Un cookie de session est ce qui dit à votre site qu'un visiteur est connecté. Qui le récupère peut se faire passer pour ce visiteur. Chaque attribut ferme un chemin différent vers ce cookie.

• Secure : le navigateur n'envoie le cookie que sur une connexion chiffrée (HTTPS). Sans lui, le cookie peut partir en clair, par exemple lors d'une redirection depuis une adresse en « http ».
• HttpOnly : le cookie reste invisible pour le code JavaScript de la page. Sans lui, un script injecté dans la page peut le lire et l'envoyer ailleurs.
• SameSite : le navigateur n'envoie pas le cookie, ou seulement dans certains cas, quand la requête part d'un autre site. Sans lui, un autre site peut déclencher une action sur le vôtre au nom d'un visiteur connecté. Il prend la valeur Strict, Lax ou None.

Quand SameSite manque, le comportement dépend du navigateur : les navigateurs récents appliquent Lax, les anciens n'appliquent aucune restriction. Cette règle est décrite dans la révision en cours de la norme des cookies, à l'IETF.

Tous les cookies n'en ont pas besoin

Les recommandations de l'ANSSI pour la mise en œuvre d'un site web sont précises sur ce point. Un cookie de session doit porter HttpOnly, et SameSite avec une autre valeur que None. Dès que le site n'est servi qu'en HTTPS, ses cookies doivent porter Secure.

Un cookie qui retient la langue ou l'acceptation du bandeau n'ouvre l'accès à rien. S'il est lisible par les scripts de la page, ce n'est pas un défaut : certains ont besoin de le lire. C'est pourquoi la liste brute des cookies sans attribut ne dit pas, à elle seule, si un site a un problème.

Ce que nous relevons sur les sites audités

Ce pourcentage porte sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026, ceux où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : le chiffre décrit nos audits, pas l'ensemble des sites.

Ce que l'audit regarde, cookie par cookie

L'audit relève les cookies que votre site pose pendant la visite de ses pages, avant tout choix dans le bandeau. Pour chacun, il note le domaine qui le pose et la présence de Secure, HttpOnly et SameSite.

Vient ensuite un jugement : parmi les cookies à qui il manque un attribut, un seul porte-t-il une session, une connexion ou une donnée personnelle ? Si oui, le constat est retenu, et le rapport nomme le cookie et ce qui lui manque. Si ce ne sont que des cookies de préférence, il n'y a rien à corriger.

Le constat retire un nombre fixe de points à la note du pilier, quel que soit le nombre de cookies concernés.

Ce qui se corrige simplement, ce qui demande un projet

Un cookie peut venir de votre propre code, d'une extension du CMS ou d'un service appelé par la page. La correction passe par celui qui le pose. Pour un cookie de votre code, ajouter les attributs est un réglage. Pour une extension, c'est souvent une option, parfois une demande à son éditeur.

Deux cas demandent plus de travail. Si votre application lit elle-même le cookie de session depuis la page, HttpOnly l'en empêche : il faut changer la façon dont elle s'identifie. Et SameSite en mode Strict n'envoie pas le cookie quand le visiteur arrive par un lien depuis un autre site, par exemple un email : selon le parcours, la connexion semble perdue. Le choix entre Strict et Lax se fait cookie par cookie, selon la façon dont les visiteurs arrivent sur le site.

Secure ne vaut que si tout le site est servi en HTTPS. C'est le rôle de l'en-tête HSTS, l'un des en-têtes de sécurité HTTP.

Ce que cette vérification ne dit pas

Par Quentin Mathis, Z29K · mis à jour le 28 septembre 2026