Les cookies
Les cookies sont placés par le serveur web sur le navigateur web via l'en-tête HTTP Set-Cookie. Le navigateur retransmet ensuite ces informations lors des prochaines requêtes au serveur via l'en-tête HTTP Cookie.
Vous devez garantir que ces cookies ne peuvent être altérés que par le serveur.
Syntaxe de cet en-tête :
Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]
L'instruction HttpOnly
L’utilisation de l’instruction “HttpOnly” empêche d’accéder aux cookies en Javascript : si malgré les protections précitées, un attaquant venait à injecter du Javascript, les cookies ne seront pas accessibles, ce qui limitera la portée de l’attaque.
En ajoutant l'instruction HttpOnly au niveau de l'en-tête HTTP Set-Cookie, le serveur informe le navigateur que le cookie ne peut être modifié . Le client se contente de récupérer et retourner le cookie envoyé par le serveur : il transite donc sur le protocole HTTP mais ne peut pas être modifié via du Javascript par exemple.
Les cookies pourraient être exploités en cas de faille XSS, vous devriez considérer l’ajout de l'instruction HttpOnly lors du Set-Cookie
Set-Cookie: third_party_var=value; HttpOnly
L'instruction Secure
En ajoutant l'instruction Secure au niveau de l'en-tête HTTP Set-Cookie, le serveur informe au navigateur qu'il n’est autorisé à retransmettre le cookie que sur des requêtes sécurisées. Seul l’attribut secure vous permettra d’empêcher qu’un Cookie ne soit jamais communiqué en HTTP simple.
Attention : vérifiez que la redirection HTTP vers HTTPS est bien en place sur votre site. Dans le cas contraire, le cookie Secure pourrait ne pas être envoyé lors d'une requête HTTP.
Set-Cookie: third_party_var=value; Secure
L'instruction SameSite
Permettant de mitiger les risques liés aux attaques de type CSRF (Cross-Site Request Forgery) et XSSI (Cross-Site Script Inclusion), le principe de l'instruction SameSite est similaire à celui des flags HttpOnly et Secure : il permet de contrôler le comportement des cookies.
Same-Site propose 2 politiques différentes, qui seront définies par les valeurs suivantes (sensibles à la casse) : Strict et Lax. Permettant de définir quand ces derniers peuvent être envoyés et quand ils ne le doivent pas.
Set-Cookie: third_party_var=value; SameSite=Lax
Lax
Les cookies sont transférables depuis le site actuel vers des sites de niveaux inférieurs et seront envoyés lors de requêtes GET (et non POST) initialisées par des sites tiers. C'est la valeur par défaut des navigateurs les plus récents.
Strict
Les cookies ne seront envoyés qu'avec les requêtes effectuées sur le domaine de même niveau, et ne seront pas envoyées sur les requêtes vers des sites tiers.
Une 3ème valeur est également, il s'agit de la valeur None :
None
Les cookies seront envoyés dans tous les contextes, rendant possibles les requêtes de type cross-origin.
None était la valeur par défaut des navigateurs, mais les navigateurs les plus récents optent désormais pour la valeur Lax comme valeur par défaut pour une meilleure défense contre les attaques de type cross-site request forgery (CSRF).
A savoir que cette valeur requiert l'attribut Secure
Set-Cookie: third_party_var=value; SameSite=None; Secure
Attention ! Strict est le mode par défaut si l’attribut SameSite est précisé. Toute erreur de frappe pour la valeur Lax aura donc pour résultat l’application du mode Strict.
Articles intéressant sur le sujet :
https://web.dev/samesite-cookies-explained/
