Les cookies sont omniprésents sur le Web et permettent aux éditeurs de stocker un certain nombre d’informations directement sur le navigateur de l’internaute.
Notamment utilisés pour identifier la session de l’utilisateur et permettre au serveur de reconnaître celui-ci tout au long de sa navigation, les cookies contiennent souvent des informations personnelles et/ou sensibles. Il convient donc de les protéger en conséquence.
Attention : l’utilisation de cookies permettant d’identifier un utilisateur ou une utilisatrice est encadrée légalement par la collecte préalable d’un consentement aux traitements que vous en ferez ultérieurement. Si l’une des solutions que vous utilisez nécessite de fonctionner sans ce consentement, n’hésitez pas à vous adresser à l’éditeur pour en faire la demande. Par exemple, et même si le tag CS Digital est spécialement conçu pour apporter à vos visiteurs toutes les garanties en termes de confidentialité et de sécurité, il nécessite un consentement préalable. Un guide de configuration est cependant disponible auprès de la CNIL, permettant un usage hors consentement.
L’en-tête HTTP Set-Cookie
Pour rappel, un cookie est généralement créé sur le navigateur à la demande du serveur pour stocker un état, qui sera ensuite retransmis sur les prochaines requêtes. Le serveur web utilise pour cela l’en-tête Set-Cookie dans une réponse HTTP.
Voici la syntaxe de cet en-tête :
Set-Cookie: =[; =] [; expires=][; domain=] [; path=][; secure][; HttpOnly]
Le cookie est identifié par un nom auquel on associe une valeur. Il peut disposer d’une durée de validité et/ou d’une date d’expiration. On notera que si les 2 instructions sont présentes, c’est la durée de validité (max-age) qui prendra le dessus. Enfin, il est possible pour le serveur de définir un chemin et un domaine pour lequel le cookie devra être utilisé. Un cookie n’est par défaut envoyé que sur le domaine responsable de l’avoir placé. Les instructions domain et path permettent éventuellement de restreindre sa portée, ou inversement de l’étendre, par exemple en autorisant son utilisation sur tous les sous-domaines.
Une première bonne pratique pour la sécurisation de vos cookies consiste justement à bien maîtriser leurs portées respectives.
Les deux dernières instructions secure et HttpOnly, portent spécifiquement sur la sécurité. On notera qu’elles n’acceptent pas de valeurs, c’est leur présence ou non qui caractérise le comportement du navigateur vis-à-vis du cookie.
Interdire l’utilisation du cookie côté client avec l’instruction HttpOnly
Un cookie peut-être positionné et utilisé par un serveur, mais aussi directement sur le navigateur en Javascript.
Dans le cas d’une faille XSS, un attaquant pourrait parvenir à injecter du Javascript, et donc potentiellement accéder aux cookies qui, rappelons-le, contiennent souvent des informations sensibles. Évidemment, il est avant tout préférable d’éviter les failles XSS. Ensuite, leur exploitation peut être empêchée par la définition d’une Content Security Policy.
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.
Interdire l’utilisation du cookie sans HTTPs avec le flag Secure
Nous le répétons régulièrement sur ce blog, HTTPs est nécessaire pour votre site internet. Si vous avez adopté ce protocole sécurisé, et que vous avez suivi les conseils précédents, vous vous dites peut-être que le cookie transite sur une communication sécurisée, qu’il n’est pas accessible en Javascript et donc non vulnérable à une attaque XSS.
Malheureusement, il reste un problème notable.
Et si votre internaute accède à votre site en HTTP, tout simplement en saisissant l’adresse directement sans préciser https:// ? Cela peut aussi être le cas si votre page comporte des contenus mixtes (ou mixed content).
Certes, la mise en place d’un en-tête HSTS (HTTP Strict Transport Security), qui permet de forcer l’utilisation du HTTPS pour toute visite ultérieure peut fortement limiter le premier cas. Mais ce n’est pas supporté par tous les navigateurs, et il reste toujours le cas de la première visite. La Content Security Policy peut mitiger le deuxième cas, en évitant tout risque de mixed content pour les navigateurs qui la supportent.
Seul l’attribut secure vous permettra d’empêcher qu’un Cookie ne soit jamais communiqué en HTTP simple.
L’intérêt de cette instruction est d’ailleurs clairement évoqué dans la RFC HTTP State Management Mechanism.
Évidemment, gardez à l’esprit qu’un cookie utilisant l’instruction Secure ne sera pas du tout envoyé sur la version HTTP simple de votre site. Attention par exemple si votre site fait encore cohabiter des espaces en HTTPs et d’autres en HTTP simple (auquel cas, nous vous invitons à migrer ces pages vers une version sécurisée qui apportera une meilleur UX à vos utilisateurs et sera mieux perçue par les moteurs de recherche).
En conclusion, n’oubliez pas que notre outil d’analyse de pages Web vous permettra en quelques instants de vous assurer que vos cookies sont sécurisés, en vérifiant la bonne utilisation de HttpOnly et de Secure !
Professionnel du web depuis plus de 15 ans, je m’intéresse à l’ensemble des sujets de la Qualité Web, à commencer par la Performance Web. Solution Expert pour Contentsquare, j’accompagne nos clients, des divisions marketing aux département IT, dans l’audit en temps-réel des problématiques techniques intervenant côté client : performance web, erreurs JS et APIS, pertinence des message affichés… afin de soutenir des stratégies d’optimisation de l’acquisition, de le conversion ou réduire le Time-to-Fix.