Cookie HTTP

Les cookies HTTP (également appelés cookies Web , cookies Internet , cookies de navigateur ou simplement cookies ) sont de petits blocs de données créés par un serveur Web pendant qu'un utilisateur navigue sur un site Web et placés sur l'ordinateur ou un autre appareil de l'utilisateur par le navigateur Web de l'utilisateur . Les cookies sont placés sur l'appareil utilisé pour accéder à un site Web, et plusieurs cookies peuvent être placés sur l'appareil d'un utilisateur au cours d'une session.

Les cookies remplissent des fonctions utiles et parfois essentielles sur le Web . Ils permettent aux serveurs Web de stocker des informations d'état (telles que les articles ajoutés au panier d'achat dans une boutique en ligne ) sur l'appareil de l'utilisateur ou de suivre l'activité de navigation de l'utilisateur (y compris le fait de cliquer sur des boutons particuliers, de se connecter ou d'enregistrer les pages visitées dans le passé ). Ils peuvent également être utilisés pour enregistrer les informations que l'utilisateur a précédemment saisies dans des champs de formulaire , telles que les noms, adresses, mots de passe et numéros de carte de paiement pour une utilisation ultérieure.

Les cookies d'authentification sont couramment utilisés par les serveurs Web pour authentifier qu'un utilisateur est connecté et avec quel compte il est connecté. Sans le cookie, les utilisateurs devraient s'authentifier en se connectant sur chaque page contenant des informations sensibles auxquelles ils souhaitent accéder. La sécurité d'un cookie d'authentification dépend généralement de la sécurité du site Web émetteur et du navigateur Web de l'utilisateur, ainsi que du cryptage ou non des données du cookie . Les vulnérabilités de sécurité peuvent permettre aux données d'un cookie d'être lues par un attaquant , utilisées pour accéder aux données de l'utilisateur ou utilisées pour accéder (avec les informations d'identification de l'utilisateur) au site Web auquel appartient le cookie (voir les scripts intersites et la falsification de requête intersites pour des exemples).

Les cookies de suivi , et en particulier les cookies de suivi tiers, sont couramment utilisés comme moyen de compiler des enregistrements à long terme des historiques de navigation des individus - un problème potentiel de confidentialité qui a incité les législateurs européens et américains à prendre des mesures en 2011. La législation européenne exige que tous les sites Web ciblant les États membres de l'Union européenne obtiennent le « consentement éclairé » des utilisateurs avant de stocker des cookies non essentiels sur leur appareil.

Le terme cookie a été inventé par le programmeur de navigateur Web Lou Montulli . Il est dérivé du terme magic cookie , qui est un paquet de données qu'un programme reçoit et renvoie sans changement, utilisé par les programmeurs Unix .

Les cookies magiques étaient déjà utilisés en informatique lorsque le programmeur informatique Lou Montulli a eu l'idée de les utiliser dans les communications Web en juin 1994. À l'époque, il était employé de Netscape Communications , qui développait une application de commerce électronique pour MCI . Vint Cerf et John Klensin représentaient MCI dans les discussions techniques avec Netscape Communications. MCI ne voulait pas que ses serveurs aient à conserver des états de transaction partiels, ce qui les a conduits à demander à Netscape de trouver un moyen de stocker cet état dans l'ordinateur de chaque utilisateur. Les cookies ont fourni une solution au problème de la mise en œuvre fiable d'un panier d'achat virtuel .

En collaboration avec John Giannandrea, Montulli a écrit la même année la spécification initiale des cookies de Netscape. La version 0.9beta de Mosaic Netscape , publiée le 13 octobre 1994, prenait en charge les cookies. La première utilisation des cookies (hors des laboratoires) consistait à vérifier si les visiteurs du site Web de Netscape avaient déjà visité le site. Montulli a déposé une demande de brevet pour la technologie des cookies en 1995, qui a été accordée en 1998. La prise en charge des cookies a été intégrée à Internet Explorer dans la version 2, publiée en octobre 1995.

À l'époque, l'introduction des cookies n'était pas largement connue du grand public. En particulier, les cookies étaient acceptés par défaut et les utilisateurs n'étaient pas informés de leur présence. Le public a entendu parler des cookies après la publication d'un article du Financial Timesde la Federal Trade Commission des États-Unis en 1996 et 1997.

Le développement des spécifications formelles des cookies était déjà en cours. En particulier, les premières discussions sur une spécification formelle ont commencé en avril 1995 sur la liste de diffusion www-talk . Un groupe de travail spécial au sein de l' Internet Engineering Task Force (IETF) a été formé. Deux propositions alternatives pour introduire l'état dans les transactions HTTP avaient été proposées respectivement par Brian Behlendorf et David Kristol. Mais le groupe, dirigé par Kristol lui-même et Lou Montulli, a rapidement décidé d'utiliser la spécification Netscape comme point de départ. En février 1996, le groupe de travail a identifié les cookies tiers comme une menace considérable pour la vie privée. La spécification produite par le groupe a finalement été publiée sous la forme de RFC 2109 en février 1997. Elle spécifie que les cookies tiers ne sont pas du tout autorisés, ou du moins pas activés par défaut. À cette époque, les sociétés de publicité utilisaient déjà des cookies tiers. La recommandation concernant les cookies tiers de la RFC 2109 n'a pas été suivie par Netscape et Internet Explorer. La RFC 2109 a été remplacée par la RFC 2965 en octobre 2000.

La RFC 2965 a ajouté un Set-Cookie2 champ d'en-tête , qui a été appelé de manière informelle « cookies de style RFC 2965 » par opposition au Set-Cookiechamp d'en-tête d'origine qui était appelé « cookies de style Netscape ». Set-Cookie2 a cependant été rarement utilisé et a été déconseillé dans la RFC 6265 en avril 2011, qui a été écrite comme une spécification définitive pour les cookies tels qu'ils sont utilisés dans le monde réel. Aucun navigateur moderne ne reconnaît le Set-Cookie2champ d'en-tête.

Un cookie de session (également appelé cookie en mémoire , cookie transitoire ou cookie non persistant ) existe uniquement dans la mémoire temporaire pendant que l'utilisateur navigue sur un site Web. Les cookies de session expirent ou sont supprimés lorsque l'utilisateur ferme le navigateur Web. Les cookies de session sont identifiés par le navigateur par l'absence d'une date d'expiration qui leur est attribuée.

Un cookie persistant expire à une date précise ou après une durée déterminée. Pendant la durée de vie du cookie persistant définie par son créateur, ses informations seront transmises au serveur chaque fois que l'utilisateur visitera le site Web auquel il appartient, ou chaque fois que l'utilisateur consultera une ressource appartenant à ce site Web à partir d'un autre site Web (comme une publicité).

Pour cette raison, les cookies persistants sont parfois appelés cookies de suivi car ils peuvent être utilisés par les annonceurs pour enregistrer des informations sur les habitudes de navigation d'un utilisateur sur une période prolongée. Les cookies persistants sont également utilisés pour des raisons telles que le maintien de la connexion des utilisateurs à leurs comptes sur les sites Web, afin d'éviter de ressaisir les informations de connexion à chaque visite.

Un cookie sécurisé ne peut être transmis que via une connexion cryptée (c'est-à-dire HTTPS ). Il ne peut pas être transmis via des connexions non cryptées (c'est-à-dire HTTP ). Cela réduit le risque que le cookie soit exposé au vol de cookie via une écoute clandestine . Un cookie est sécurisé en ajoutant l' Secureindicateur au cookie.

Un cookie http uniquement n'est pas accessible par les API côté client, telles que JavaScript . Cette restriction élimine la menace de vol de cookies via des scripts intersites (XSS). Cependant, le cookie reste vulnérable aux attaques de traçage intersites (XST) et de falsification de requête intersites (CSRF). Un cookie reçoit cette caractéristique en ajoutant l' HttpOnlyindicateur au cookie.

En 2016, la version 51 de Google Chrome a introduit un nouveau type de cookie avec l'attribut SameSiteavec les valeurs possibles de Strict, Laxou None. Avec l'attribut SameSite=Strict, les navigateurs enverraient uniquement des cookies à un domaine cible identique au domaine d'origine. Cela atténuerait efficacement les attaques de falsification de requête intersite (CSRF). Avec SameSite=Lax, les navigateurs enverraient des cookies avec des requêtes à un domaine cible même s'il est différent du domaine d'origine, mais uniquement pour les requêtes sûres telles que GET (POST n'est pas sûr) et non pour les cookies tiers (à l'intérieur d'iframe). L'attribut SameSite=Noneautoriserait les cookies tiers (intersites), cependant, la plupart des navigateurs nécessitent un attribut sécurisé sur les cookies SameSite=None.

Le cookie du même site est intégré dans un nouveau projet de RFC pour « Cookies : mécanisme de gestion de l'état HTTP » pour mettre à jour la RFC 6265 (si elle est approuvée).

Chrome, Firefox et Edge ont commencé à prendre en charge les cookies du même site. La clé du déploiement est le traitement des cookies existants sans l'attribut SameSite défini, Chrome a traité ces cookies existants comme si SameSite=None, ce qui permettrait à tous les sites Web/applications de fonctionner comme avant. Google avait l'intention de modifier cette valeur par défaut SameSite=Laxdans Chrome 80, dont la sortie est prévue en février 2020, mais en raison du risque de rupture des applications/sites Web qui s'appuient sur des cookies tiers/intersites et des circonstances liées au COVID-19 , Google a reporté ce changement à Chrome 84.

Un supercookie est un cookie dont l'origine est un domaine de premier niveau (tel que .com) ou un suffixe public (tel que .co.uk). Les cookies ordinaires, en revanche, ont pour origine un nom de domaine spécifique, tel que example.com.

Les supercookies peuvent constituer un problème de sécurité potentiel et sont donc souvent bloqués par les navigateurs Web. S'ils sont débloqués par le navigateur, un attaquant contrôlant un site Web malveillant pourrait définir un supercookie et potentiellement perturber ou usurper l'identité de demandes d'utilisateurs légitimes adressées à un autre site Web qui partage le même domaine de premier niveau ou le même suffixe public que le site Web malveillant. Par exemple, un supercookie avec une origine de .com, pourrait affecter de manière malveillante une demande adressée à example.com, même si le cookie ne provient pas de example.com. Cela peut être utilisé pour falsifier des connexions ou modifier les informations utilisateur.

La liste publique des suffixes permet d'atténuer le risque posé par les supercookies. La liste publique des suffixes est une initiative multifournisseurs qui vise à fournir une liste précise et à jour des suffixes de noms de domaine. Les anciennes versions des navigateurs peuvent ne pas disposer d'une liste à jour et seront donc vulnérables aux supercookies de certains domaines.

Le terme supercookie est parfois utilisé pour les technologies de suivi qui ne reposent pas sur les cookies HTTP. Deux de ces mécanismes de supercookie ont été découverts sur les sites Web de Microsoft en août 2011 : la synchronisation des cookies qui a régénéré les cookies MUID (identifiant unique de la machine) et les cookies ETag . En raison de l'attention des médias, Microsoft a par la suite désactivé ce code. Dans un article de blog de 2021, Mozilla a utilisé le terme supercookie pour désigner l'utilisation du cache du navigateur comme moyen de suivre les utilisateurs sur les sites.

Un cookie zombie est un ensemble de données et de codes qui ont été placés par un serveur Web sur l'ordinateur ou un autre appareil d'un visiteur dans un emplacement caché en dehors de l' emplacement de stockage des cookies dédié du navigateur Web du visiteur , et qui recrée automatiquement un cookie HTTP en tant que cookie normal après la suppression du cookie d'origine. Le cookie zombie peut être stocké dans plusieurs emplacements, tels que l'objet partagé local Flash , le stockage Web HTML5 et d'autres emplacements côté client et même côté serveur, et lorsqu'une absence est détectée dans l'un des emplacements, l'instance manquante est recréée par le code JavaScript à l'aide des données stockées dans d'autres emplacements.

Un cookie wall apparaît sur un site Web et informe l'utilisateur de l'utilisation des cookies du site Web. Il n'a pas d'option de rejet et le site Web n'est pas accessible sans cookies de suivi.

Un cookie est composé des éléments suivants :

1. Nom
2. Valeur
3. Zéro ou plusieurs attributs ( paires nom/valeur ). Les attributs stockent des informations telles que l'expiration du cookie, le domaine et les indicateurs (tels que Secureet HttpOnly).

Les cookies ont été introduits à l'origine pour permettre aux utilisateurs d'enregistrer les articles qu'ils souhaitent acheter lorsqu'ils naviguent sur un site Web (un panier d'achat virtuel ou un panier d'achat ). Aujourd'hui, cependant, le contenu du panier d'achat d'un utilisateur est généralement stocké dans une base de données sur le serveur, plutôt que dans un cookie sur le client. Pour garder une trace de l'utilisateur affecté à quel panier d'achat, le serveur envoie un cookie au client qui contient un identifiant de session unique (généralement, une longue chaîne de lettres et de chiffres aléatoires). Étant donné que les cookies sont envoyés au serveur à chaque demande du client, cet identifiant de session sera renvoyé au serveur chaque fois que l'utilisateur visite une nouvelle page du site Web, ce qui permet au serveur de savoir quel panier d'achat afficher à l'utilisateur.

Une autre utilisation courante des cookies est la connexion aux sites Web. Lorsque l'utilisateur visite la page de connexion d'un site Web, le serveur Web envoie généralement au client un cookie contenant un identifiant de session unique. Lorsque l'utilisateur se connecte avec succès, le serveur se souvient que cet identifiant de session particulier a été authentifié et accorde à l'utilisateur l'accès à ses services.

Les cookies de session ne contenant qu'un identifiant de session unique, la quantité d'informations personnelles qu'un site Web peut enregistrer sur chaque utilisateur est pratiquement illimitée. Le site Web n'est pas limité par les restrictions concernant la taille d'un cookie. Les cookies de session contribuent également à améliorer les temps de chargement des pages, car la quantité d'informations contenues dans un cookie de session est faible et nécessite peu de bande passante.

Les cookies peuvent être utilisés pour mémoriser des informations sur l'utilisateur afin de lui montrer du contenu pertinent au fil du temps. Par exemple, un serveur Web peut envoyer un cookie contenant le nom d'utilisateur utilisé pour la dernière fois pour se connecter à un site Web, afin qu'il soit automatiquement renseigné la prochaine fois que l'utilisateur se connecte.

De nombreux sites Web utilisent des cookies pour personnaliser le site en fonction des préférences de l'utilisateur. Les utilisateurs sélectionnent leurs préférences en les saisissant dans un formulaire Web et en soumettant le formulaire au serveur. Le serveur encode les préférences dans un cookie et renvoie le cookie au navigateur. De cette façon, chaque fois que l'utilisateur accède à une page du site Web, le serveur peut personnaliser la page en fonction des préférences de l'utilisateur. Par exemple, le moteur de recherche Google utilisait autrefois des cookies pour permettre aux utilisateurs (même non enregistrés) de décider du nombre de résultats de recherche par page qu'ils souhaitaient voir. De plus, DuckDuckGo utilise des cookies pour permettre aux utilisateurs de définir les préférences d'affichage comme les couleurs de la page Web.

Les cookies de suivi sont utilisés pour suivre les habitudes de navigation des utilisateurs sur le Web. Cela peut également être fait dans une certaine mesure en utilisant l' adresse IP de l'ordinateur demandant la page ou le champ de référence de l'en-tête de la requête HTTP , mais les cookies permettent une plus grande précision. Cela peut être démontré comme suit :

1. Si l'utilisateur demande une page du site, mais que la requête ne contient aucun cookie, le serveur suppose qu'il s'agit de la première page visitée par l'utilisateur. Le serveur crée alors un identifiant unique (généralement une chaîne de lettres et de chiffres aléatoires) et l'envoie sous forme de cookie au navigateur avec la page demandée.
2. À partir de ce moment, le cookie sera automatiquement envoyé par le navigateur au serveur à chaque fois qu'une nouvelle page du site sera demandée. Le serveur envoie non seulement la page comme d'habitude, mais enregistre également l'URL de la page demandée, la date/heure de la demande et le cookie dans un fichier journal.

En analysant ce fichier journal, il est ensuite possible de savoir quelles pages l'utilisateur a visitées, dans quel ordre et pendant combien de temps.

Les entreprises exploitent les habitudes de navigation des utilisateurs en suivant les cookies pour recueillir des informations sur leurs habitudes d'achat. Le Wall Street Journal a constaté que les cinquante plus grands sites Web américains ont installé en moyenne soixante-quatre technologies de suivi sur les ordinateurs, ce qui a donné lieu à un total de 3 180 fichiers de suivi. Les données peuvent ensuite être collectées et vendues aux entreprises qui soumissionnent.

Les cookies sont des éléments de données arbitraires, généralement choisis et envoyés en premier par le serveur Web, puis stockés sur l'ordinateur client par le navigateur Web. Le navigateur les renvoie ensuite au serveur à chaque requête, introduisant des états (mémoire des événements précédents) dans des transactions HTTP autrement sans état . Sans cookies, chaque récupération d'une page Web ou d'un composant d'une page Web serait un événement isolé, largement sans rapport avec toutes les autres pages consultées par l'utilisateur sur le site Web. Bien que les cookies soient généralement définis par le serveur Web, ils peuvent également être définis par le client à l'aide d'un langage de script tel que JavaScript (à moins que l'indicateur du cookie HttpOnlyne soit défini, auquel cas le cookie ne peut pas être modifié par les langages de script).

Les spécifications des cookies exigent que les navigateurs répondent aux exigences suivantes pour prendre en charge les cookies :

• Peut prendre en charge des cookies d'une taille maximale de 4 096 octets .
• Peut prendre en charge au moins 50 cookies par domaine (c'est-à-dire par site Web).
• Peut prendre en charge au moins 3 000 cookies au total.

Les cookies sont définis à l'aide du Set-Cookie champ d'en-tête , envoyé dans une réponse HTTP du serveur Web. Ce champ d'en-tête indique au navigateur Web de stocker le cookie et de le renvoyer lors de futures requêtes au serveur (le navigateur ignorera ce champ d'en-tête s'il ne prend pas en charge les cookies ou s'il les a désactivés).

À titre d’exemple, le navigateur envoie sa première requête HTTP pour la page d’accueil du www.example.orgsite Web :

OBTENIR 
/index.html 
HTTP / 1.1 
Hôte : 
www.example.org 
...

Le serveur répond avec deux Set-Cookiechamps d'en-tête :

HTTP / 1.0 
200 
OK 
Type de contenu : 
texte/html 
Set-Cookie : 
thème=light 
Set-Cookie : 
sessionToken=abc123 ; Expire=mer. 09 juin 2021 10:18:14 GMT 
...

La réponse HTTP du serveur contient le contenu de la page d'accueil du site Web. Mais elle demande également au navigateur de définir deux cookies. Le premier, theme , est considéré comme un cookie de session car il ne possède pas d' attribut Expiresor Max-Age. Les cookies de session sont destinés à être supprimés par le navigateur lorsque celui-ci se ferme. Le second, sessionToken , est considéré comme un cookie persistant car il contient un Expiresattribut qui demande au navigateur de supprimer le cookie à une date et une heure spécifiques.

Ensuite, le navigateur envoie une autre demande pour visiter la spec.htmlpage du site Web. Cette demande contient un Cookiechamp d'en-tête, qui contient les deux cookies que le serveur a demandé au navigateur de définir :

OBTENIR 
/spec.html 
HTTP / 1.1 
Hôte : 
www.example.org 
Cookie : 
theme=light; sessionToken=abc123 
…

De cette façon, le serveur sait que cette requête HTTP est liée à la précédente. Le serveur répond en envoyant la page demandée, en incluant éventuellement d'autres Set-Cookiechamps d'en-tête dans la réponse HTTP afin d'indiquer au navigateur d'ajouter de nouveaux cookies, de modifier les cookies existants ou de supprimer les cookies existants. Pour supprimer un cookie, le serveur doit inclure un Set-Cookiechamp d'en-tête avec une date d'expiration dans le passé.

La valeur d'un cookie peut être constituée de tout caractère ASCII imprimable ( !à ~, Unicode \u0021 à \u007E) à l'exclusion des caractères, et ;et des espaces . Le nom d'un cookie exclut les mêmes caractères, ainsi que , car c'est le délimiteur entre le nom et la valeur. La norme de cookie RFC 2965 est plus restrictive mais n'est pas implémentée par les navigateurs. =

Le terme « cookie crumb » est parfois utilisé pour désigner la paire nom–valeur d'un cookie.

Les cookies peuvent également être définis par des langages de script tels que JavaScript qui s'exécutent dans le navigateur. En JavaScript, l'objet document.cookieest utilisé à cette fin. Par exemple, l'instruction document.cookie = "temperature=20"crée un cookie de nom temperature et de valeur 20 .

En plus d'un nom et d'une valeur, les cookies peuvent également avoir un ou plusieurs attributs. Les navigateurs n'incluent pas les attributs de cookie dans les requêtes adressées au serveur : ils envoient uniquement le nom et la valeur du cookie. Les attributs de cookie sont utilisés par les navigateurs pour déterminer quand supprimer un cookie, bloquer un cookie ou envoyer un cookie au serveur.

Les attributs Domainet Pathdéfinissent la portée du cookie. Ils indiquent essentiellement au navigateur à quel site Web appartient le cookie. Pour des raisons de sécurité, les cookies ne peuvent être définis que sur le domaine principal de la ressource actuelle et ses sous-domaines, et non sur un autre domaine et ses sous-domaines. Par exemple, le site Web example.orgne peut pas définir un cookie dont le domaine est , foo.comcar cela permettrait au site Web example.orgde contrôler les cookies du domaine foo.com.

DomainSi les attributs et les cookies Pathne sont pas spécifiés par le serveur, ils correspondent par défaut au domaine et au chemin de la ressource demandée. Cependant, dans la plupart des navigateurs, il existe une différence entre un cookie défini foo.comsans domaine et un cookie défini avec le foo.comdomaine. Dans le premier cas, le cookie ne sera envoyé que pour les demandes adressées à foo.com, également appelé cookie réservé à l'hôte. Dans le second cas, tous les sous-domaines sont également inclus (par exemple, docs.foo.com). Une exception notable à cette règle générale est Edge avant Windows 10 RS3 et Internet Explorer avant IE 11 et Windows 10 RS4 (avril 2018), qui envoient toujours des cookies aux sous-domaines, que le cookie ait été défini avec ou sans domaine.

Vous trouverez ci-dessous un exemple de certains Set-Cookiechamps d'en-tête dans la réponse HTTP d'un site Web après la connexion d'un utilisateur. La requête HTTP a été envoyée à une page Web dans le docs.foo.comsous-domaine :

HTTP / 1.0 
200 
OK 
Set-Cookie : 
LSID=DQAAAK…Eaem_vYg; Chemin=/accounts; Expire=mer. 13 janv. 2021 22:23:01 GMT; Sécurisé; HttpOnly 
Set-Cookie : 
HSID=AYQEVn…DKrdst; Domaine=.foo.com; Chemin=/; Expire=mer. 13 janv. 2021 22:23:01 GMT; HttpOnly 
Set-Cookie : 
SSID=Ap4P…GTEq; Domaine=foo.com; Chemin=/; Expire=mer. 13 janv. 2021 22:23:01 GMT; Sécurisé; HttpOnly 
…

Le premier cookie, LSID, n'a pas Domaind'attribut et possède un Pathattribut défini sur /accounts. Cela indique au navigateur d'utiliser le cookie uniquement lors de la demande de pages contenues dans docs.foo.com/accounts(le domaine est dérivé du domaine de demande). Les deux autres cookies, HSIDet SSID, seraient utilisés lorsque le navigateur demande un sous-domaine dans .foo.comn'importe quel chemin (par exemple www.foo.com/bar). Le point de préfixe est facultatif dans les normes récentes, mais peut être ajouté pour la compatibilité avec les implémentations basées sur la RFC 2109.

L' Expiresattribut définit une date et une heure spécifiques auxquelles le navigateur doit supprimer le cookie. La date et l'heure sont spécifiées sous la forme Wdy, DD Mon YYYY HH:MM:SS GMT, ou sous la forme Wdy, DD Mon YY HH:MM:SS GMTpour les valeurs de YY où YY est supérieur ou égal à 0 et inférieur ou égal à 69.

L'attribut peut également Max-Ageêtre utilisé pour définir l'expiration du cookie sous la forme d'un intervalle de secondes dans le futur, par rapport au moment où le navigateur a reçu le cookie. Vous trouverez ci-dessous un exemple de trois Set-Cookiechamps d'en-tête reçus d'un site Web après la connexion d'un utilisateur :

HTTP / 1.0 
200 
OK 
Set-Cookie : 
lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expire=mar. 15 janv. 2013 21:47:38 GMT; Chemin=/; Domaine=.example.com; HttpOnly 
Set-Cookie : 
made_write_conn=1295214458; Chemin=/; Domaine=.example.com 
Set-Cookie : 
reg_fb_gate=deleted; Expire=jeu. 01 janv. 1970 00:00:01 GMT; Chemin=/; Domaine=.example.com; HttpOnly

Le premier cookie, lu, doit expirer le 15 janvier 2013. Il sera utilisé par le navigateur client jusqu'à cette date. Le deuxième cookie, made_write_conn, n'a pas de date d'expiration, ce qui en fait un cookie de session. Il sera supprimé une fois que l'utilisateur aura fermé son navigateur. Le troisième cookie, reg_fb_gate, a sa valeur modifiée en removed , avec une heure d'expiration dans le passé. Le navigateur supprimera ce cookie immédiatement car son heure d'expiration est dans le passé. Notez que le cookie ne sera supprimé que si les attributs domain et path dans le Set-Cookiechamp correspondent aux valeurs utilisées lors de la création du cookie.

Depuis 2016, Internet Explorer ne prend pas en charge Max-Age.

Les attributs Secureet HttpOnlyn'ont pas de valeurs associées. En fait, la présence de leurs noms d'attributs indique que leurs comportements doivent être activés.

L' Secureattribut est destiné à limiter la communication des cookies à une transmission cryptée, en demandant aux navigateurs d'utiliser les cookies uniquement via des connexions sécurisées/cryptées . Cependant, si un serveur Web définit un cookie avec un attribut sécurisé à partir d'une connexion non sécurisée, le cookie peut toujours être intercepté lorsqu'il est envoyé à l'utilisateur par des attaques de type "man-in-the-middle" . Par conséquent, pour une sécurité maximale, les cookies avec l'attribut Secure ne doivent être définis que via une connexion sécurisée.

L' HttpOnlyattribut indique aux navigateurs de ne pas exposer les cookies via des canaux autres que les requêtes HTTP (et HTTPS). Cela signifie que le cookie n'est pas accessible via des langages de script côté client (notamment JavaScript ) et ne peut donc pas être volé facilement via des scripts intersites (une technique d'attaque omniprésente).

La plupart des navigateurs modernes prennent en charge les cookies et permettent à l'utilisateur de les désactiver. Voici quelques options courantes :

• Pour activer ou désactiver complètement les cookies, afin qu'ils soient toujours acceptés ou toujours bloqués.
• Pour afficher et supprimer sélectivement les cookies à l'aide d'un gestionnaire de cookies.
• Pour effacer complètement toutes les données privées, y compris les cookies.

Il existe également des outils complémentaires permettant de gérer les autorisations des cookies.

Les cookies ont des implications importantes pour la confidentialité et l'anonymat des utilisateurs du Web. Alors que les cookies sont envoyés uniquement au serveur qui les a définis ou à un serveur du même domaine Internet, une page Web peut contenir des images ou d'autres composants stockés sur des serveurs d'autres domaines. Les cookies définis lors de la récupération de ces composants sont appelés cookies tiers . Un cookie tiers appartient à un domaine différent de celui affiché dans la barre d'adresse. Ce type de cookie apparaît généralement lorsque les pages Web présentent du contenu provenant de sites Web externes, tels que des bannières publicitaires . Cela ouvre la possibilité de suivre l'historique de navigation de l'utilisateur et est utilisé par les annonceurs pour diffuser des publicités pertinentes à chaque utilisateur.

À titre d'exemple, supposons qu'un utilisateur visite www.example.org. Ce site Web contient une publicité de ad.foxytracking.com, qui, une fois téléchargée, définit un cookie appartenant au domaine de la publicité ( ad.foxytracking.com). Ensuite, l'utilisateur visite un autre site Web, www.foo.com, qui contient également une publicité de ad.foxytracking.comet définit un cookie appartenant à ce domaine ( ad.foxytracking.com). Finalement, ces deux cookies seront envoyés à l'annonceur lors du chargement de ses publicités ou de la visite de son site Web. L'annonceur peut ensuite utiliser ces cookies pour créer un historique de navigation de l'utilisateur sur tous les sites Web qui ont des publicités de cet annonceur, grâce à l'utilisation du champ d'en-tête de référence HTTP .

En 2014 , certains sites Web définissaient des cookies lisibles par plus de 100 domaines tiers. En moyenne, un seul site Web définissait 10 cookies, avec un nombre maximal de cookies (internes et tiers) atteignant plus de 800.

Les anciennes normes relatives aux cookies, RFC 2109 et RFC 2965, recommandent aux navigateurs de protéger la confidentialité des utilisateurs et de ne pas autoriser le partage de cookies entre les serveurs par défaut. Cependant, la nouvelle norme, RFC 6265, permet explicitement aux agents utilisateurs d'implémenter la politique de cookies tiers qu'ils souhaitent. La plupart des navigateurs Web modernes contiennent des paramètres de confidentialité qui peuvent bloquer les cookies tiers. Depuis 2020, Apple Safari , Firefox , et Brave bloquent tous les cookies tiers par défaut. Safari permet aux sites intégrés d'utiliser l'API Storage Access pour demander l'autorisation de définir des cookies propriétaires. En mai 2020, Google Chrome 83 a introduit de nouvelles fonctionnalités pour bloquer les cookies tiers par défaut dans son mode Incognito pour la navigation privée, rendant le blocage facultatif pendant la navigation normale. La même mise à jour a également ajouté une option pour bloquer les cookies propriétaires. En avril 2024, Chrome a reporté le blocage des cookies tiers par défaut à 2025. En juillet 2024, Google a annoncé son intention d'éviter de bloquer les cookies tiers par défaut et d'inviter plutôt les utilisateurs à autoriser les cookies tiers.

La possibilité de créer un profil des utilisateurs constitue une menace pour la vie privée, en particulier lorsque le suivi est effectué sur plusieurs domaines à l'aide de cookies tiers. C'est pourquoi certains pays disposent d'une législation sur les cookies.

Les opérateurs de sites Web qui ne divulguent pas aux consommateurs l'utilisation de cookies tiers courent le risque de nuire à la confiance des consommateurs si l'utilisation de cookies est découverte. Une divulgation claire (par exemple dans une politique de confidentialité ) tend à éliminer tout effet négatif de cette découverte de cookies.

En 2000, le gouvernement américain a mis en place des règles strictes concernant l'installation de cookies après avoir découvert que le bureau de la politique antidrogue de la Maison Blanche utilisait des cookies pour suivre les utilisateurs qui consultaient ses publicités antidrogue en ligne. En 2002, Daniel Brandt, militant pour la protection de la vie privée, a découvert que la CIA avait laissé des cookies persistants sur les ordinateurs des visiteurs de son site Web. Lorsqu'elle a été informée qu'elle enfreignait cette politique, la CIA a déclaré que ces cookies n'avaient pas été installés intentionnellement et a cessé de les installer. Le 25 décembre 2005, Brandt a découvert que la National Security Agency (NSA) avait laissé deux cookies persistants sur les ordinateurs des visiteurs en raison d'une mise à jour logicielle. Après avoir été informée, la NSA a immédiatement désactivé les cookies.

En 2002, l'Union européenne a lancé la directive sur la vie privée et les communications électroniques (directive e-Privacy), une politique exigeant le consentement des utilisateurs finaux pour le placement de cookies et de technologies similaires pour stocker et accéder aux informations sur l'équipement des utilisateurs. En particulier, l'article 5, paragraphe 3, stipule que le stockage de données techniquement inutiles sur l'ordinateur d'un utilisateur ne peut être effectué que si l'utilisateur est informé de la manière dont ces données sont utilisées et s'il a la possibilité de refuser cette opération de stockage. La directive n'exige pas que les utilisateurs autorisent ou soient informés de l'utilisation de cookies qui sont fonctionnellement nécessaires pour fournir un service qu'ils ont demandé, par exemple pour conserver les paramètres, stocker les sessions de connexion ou mémoriser le contenu du panier d'achat d'un utilisateur.

En 2009, la loi a été modifiée par la directive 2009/136/CE, qui comprenait une modification de l'article 5, paragraphe 3. Au lieu d'offrir aux utilisateurs la possibilité de refuser le stockage de cookies, la directive révisée exige que le consentement soit obtenu pour le stockage de cookies. La définition du consentement est renvoyée à la définition de la législation européenne sur la protection des données, d'abord la directive sur la protection des données de 1995, puis le règlement général sur la protection des données (RGPD). Comme la définition du consentement a été renforcée dans le texte du RGPD, cela a eu pour effet d'augmenter la qualité du consentement requis par ceux qui stockent et accèdent à des informations telles que les cookies sur les appareils des utilisateurs. Cependant, dans une affaire tranchée en vertu de la directive sur la protection des données, la Cour de justice de l'Union européenne a ultérieurement confirmé que la loi précédente impliquait la même qualité de consentement forte que l'instrument actuel. En plus de l'exigence de consentement qui découle du stockage ou de l'accès à des informations sur le terminal d'un utilisateur, les informations contenues dans de nombreux cookies seront considérées comme des données personnelles en vertu du seul RGPD et nécessiteront une base juridique pour être traitées. Il en est ainsi depuis la directive sur la protection des données de 1995, qui utilisait une définition identique des données personnelles, bien que le RGPD, dans son considérant interprétatif 30, précise que les identifiants de cookies sont inclus. Bien que tous les traitements de données au titre du RGPD ne nécessitent pas de consentement, les caractéristiques de la publicité comportementale signifient qu'il est difficile, voire impossible, de justifier ce traitement sur la base d'un autre motif.

Le consentement, dans le cadre de la combinaison du RGPD et de la directive sur la vie privée en ligne, doit remplir un certain nombre de conditions en ce qui concerne les cookies. Il doit être donné librement et sans ambiguïté : les cases pré-cochées ont été interdites dans la directive sur la protection des données de 1995 et dans le RGPD (considérant 32). Le RGPD précise que le consentement doit être « aussi facile à retirer qu'à donner », ce qui signifie qu'un bouton « rejeter tout » doit être aussi facile d'accès en termes de clics et de visibilité qu'un bouton « accepter tout ». Il doit être spécifique et éclairé, ce qui signifie que le consentement concerne des finalités particulières d'utilisation de ces données, et que toutes les organisations souhaitant utiliser ce consentement doivent être spécifiquement nommées. La Cour de justice de l'Union européenne a également statué que le consentement doit être « efficace et opportun », ce qui signifie qu'il doit être obtenu avant que les cookies ne soient déposés et que le traitement des données ne commence plutôt qu'après.

La réponse du secteur a été largement négative. Robert Bond, du cabinet d'avocats Speechly Bircham, décrit les effets comme « de grande envergure et incroyablement onéreux » pour « toutes les entreprises britanniques ». Simon Davis, de Privacy International, soutient qu'une application appropriée « détruirait l'ensemble du secteur ». Cependant, les chercheurs notent que la nature onéreuse des fenêtres contextuelles de cookies découle d'une tentative de continuer à exploiter un modèle commercial par le biais de demandes alambiquées qui peuvent être incompatibles avec le RGPD.

Les études universitaires et les régulateurs décrivent tous deux un non-respect généralisé de la loi. Une étude portant sur 10 000 sites Web britanniques a révélé que seulement 11,8 % des sites respectaient les exigences légales minimales, et que seulement 33,4 % des sites Web étudiés fournissaient un mécanisme de rejet des cookies aussi simple à utiliser que de les accepter. Une étude portant sur 17 000 sites Web a révélé que 84 % des sites ne respectaient pas ce critère, constatant en outre que beaucoup d'entre eux déposaient des cookies tiers sans aucun préavis. Le régulateur britannique, l' Information Commissioner's Office , a déclaré en 2019 que le « Cadre de transparence et de consentement » du secteur, élaboré par le groupe de technologie publicitaire Interactive Advertising Bureau, était « insuffisant pour garantir la transparence et le traitement équitable des données personnelles en question et donc également insuffisant pour assurer un consentement libre et éclairé, avec les implications qui en découlent pour la conformité au PECR [e-Privacy] ». De nombreuses entreprises qui vendent des solutions de conformité (plateformes de gestion du consentement) permettent que celles-ci soient configurées de manière manifestement illégale, ce qui, selon les chercheurs, soulève des questions quant à la répartition appropriée de la responsabilité.

Une spécification W3C appelée P3P a été proposée pour que les serveurs communiquent leur politique de confidentialité aux navigateurs, permettant ainsi une gestion automatique et configurable par l'utilisateur. Cependant, peu de sites Web mettent en œuvre la spécification et le W3C a interrompu ses travaux sur la spécification.

Les cookies tiers peuvent être bloqués par la plupart des navigateurs pour augmenter la confidentialité et réduire le suivi par les sociétés de publicité et de suivi sans affecter négativement l'expérience Web de l'utilisateur sur tous les sites. Certains sites utilisent des « murs de cookies », qui conditionnent l'accès à un site à l'autorisation des cookies soit techniquement dans un navigateur, en appuyant sur « accepter », ou les deux. En 2020, le Comité européen de la protection des données , composé de tous les régulateurs de la protection des données de l'UE, a déclaré que les murs de cookies étaient illégaux.

Pour que le consentement soit donné librement, l'accès aux services et fonctionnalités ne doit pas être conditionné au consentement d'un utilisateur au stockage d'informations, ou à l'obtention de l'accès à des informations déjà stockées, dans l'équipement terminal d'un utilisateur (ce que l'on appelle les cookies walls).

De nombreux opérateurs publicitaires proposent une option de refus de la publicité comportementale, avec un cookie générique dans le navigateur qui bloque la publicité comportementale. Cependant, cette option est souvent inefficace contre de nombreuses formes de suivi, comme le suivi de première partie qui gagne en popularité pour éviter l'impact du blocage des cookies tiers par les navigateurs. De plus, si un tel paramètre est plus difficile à mettre en place que l'acceptation du suivi, il reste contraire aux conditions de la directive sur la vie privée et les communications électroniques.