Recettes de cookies propriétaires

Découvrez comment définir des cookies propriétaires pour assurer la sécurité, assurer la compatibilité entre les navigateurs et réduire les risques de défaillance après l'abandon des cookies tiers.

Milica Mihajlija

Les cookies peuvent être propriétaires ou tiers en fonction du contexte de l'utilisateur. en fonction du site sur lequel se trouve l'utilisateur à ce moment précis. Si le domaine enregistrable et le schéma du cookie correspondent à la page de premier niveau actuelle, c'est-à-dire à ce qui est affiché dans la barre d'adresse du navigateur, le cookie est considéré comme provenant du même site que la page. Il est généralement appelé cookie propriétaire.

Les cookies provenant de domaines autres que celui du site actuel sont généralement appelés cookies tiers.

Si le cookie que vous définissez n'est pas utilisé sur plusieurs sites (par exemple, pour gérer des sessions sur votre site), mais jamais dans un iFrame inter-sites, ce cookie est toujours utilisé dans un contexte propriétaire.

Par défaut, les cookies peuvent être partagés entre plusieurs sites, accessibles via JavaScript et envoyés via des connexions HTTP, ce qui présente certains risques en matière de sécurité et de confidentialité. Nous nous efforçons en permanence d'améliorer le comportement par défaut. Toutefois, grâce à la Privacy Sandbox et à d'autres propositions telles que les cookies liés à l'origine, vous pouvez faire beaucoup de choses aujourd'hui en définissant des attributs supplémentaires sur vos cookies.

La configuration suivante est une bonne pratique, car elle garantit la sécurité et la compatibilité entre les navigateurs pour la plupart des cookies propriétaires. Vous disposerez ainsi d'une base sécurisée que vous pourrez ajuster pour n'accorder des autorisations qu'en cas de nécessité. Cet article couvre également les variantes de recettes pour certains cas d'utilisation spécifiques.

La recette

Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Détails

Host est un préfixe facultatif qui rend certains attributs obligatoires et en interdit d'autres:

  • Secure doit être présent
  • Domain doit être omis
  • Path doit être /

Avec l'ajout de Host, vous pouvez compter sur le navigateur pour vérifier si ces attributs sont conformes aux règles __Host et refuser le cookie si ce n'est pas le cas.

Secure protège les cookies contre le vol de cookies sur les réseaux non sécurisés, car il autorise uniquement l'envoi de cookies via des connexions HTTPS. Si vous n'avez pas complètement migré votre site vers HTTPS, faites-le en priorité.

L'attribut Domain indique les hôtes qui peuvent recevoir un cookie. Si vous l'omettez, le cookie sera limité à l'hôte actuel des documents, à l'exclusion des sous-domaines: le cookie pour example.com sera envoyé à chaque requête à example.com, mais pas à celles envoyées à images.example.com. Si plusieurs de vos applications s'exécutent sur différents sous-domaines, vous réduisez ainsi le risque qu'un domaine compromis se connecte aux autres.

Path indique le chemin d'accès qui doit exister dans l'URL demandée pour que le navigateur envoie l'en-tête Cookie. Si vous définissez Path=/, le cookie est envoyé à tous les chemins d'URL de ce domaine. L'absence de Domain et d'Path=/ permet de lier le cookie à l'origine le plus près possible. Il se comporte donc de la même manière qu'un autre stockage côté client tel que LocalStorage. Il n'y a aucune confusion quant au fait que example.com/a peut recevoir des valeurs différentes pour example.com/b.

L'attribut HttpOnly ajoute une protection contre les scripts tiers malveillants sur vos sites en restreignant l'accès JavaScript. Elle autorise l'envoi d'un cookie uniquement dans les en-têtes de requête et les rend indisponibles pour JavaScript à l'aide de document.cookie.

Max-Age limite la durée de vie d'un cookie, car les sessions de navigateur peuvent durer très longtemps, et vous ne voulez pas que des cookies obsolètes ne soient jamais obsolètes. Il est utile pour les cookies à court terme, tels que les sessions utilisateur, ou encore pour les cookies plus courts tels que les jetons d'envoi de formulaires. Max-Age est défini en secondes et, dans l'exemple précédent, il est défini sur 7776000 secondes, soit 90 jours. Il s'agit d'une valeur par défaut raisonnable, que vous pouvez modifier en fonction de votre cas d'utilisation.

SameSite=Lax limite l'envoi du cookie pour des requêtes effectuées sur un même site. En d'autres termes, lorsque la requête correspond au contexte de navigation actuel, c'est-à-dire au site de premier niveau que l'utilisateur visite actuellement et qui s'affiche dans sa barre d'adresse. SameSite=Lax est le paramètre par défaut dans les navigateurs récents, mais il est recommandé de le spécifier pour assurer la compatibilité avec tous les navigateurs dont les valeurs par défaut peuvent être différentes. En marquant explicitement le cookie comme étant associé au même site, vous le limitez à vos contextes propriétaires. Vous ne devriez donc pas avoir à modifier ce cookie lorsque les cookies tiers disparaissent.

Pour en savoir plus sur les différents attributs de cookie, consultez la documentation de Set-Cookie sur MDN.

Si votre site comporte des sous-domaines et que vous souhaitez n'avoir qu'une seule session sur chacun d'eux, le préfixe Host peut être trop restrictif. Par exemple, news.site peut avoir des sous-domaines pour des thèmes tels que finance.news.site et sport.news.site, et vous souhaitez disposer d'une session utilisateur sur chacun de ces sous-domaines. Dans ce cas, utilisez le préfixe __Secure au lieu de __Host et spécifiez Domain.

La recette

Set-Cookie:
__Secure-cookie-name=cookie-value;
Secure;
Domain=news.site;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Détails

Secure est un préfixe facultatif qui affirme moins d'exigences que Host: il requiert uniquement que le cookie soit défini avec l'attribut Secure.

Bien que les cookies SameSite=Lax ne soient pas envoyés lors de sous-requêtes intersites (par exemple, lors du chargement d'images ou d'iFrames intégrés sur un site tiers), ils sont envoyés lorsqu'un utilisateur accède au site d'origine (par exemple, lorsqu'il suit un lien depuis un autre site).

Vous pouvez restreindre davantage l'accès aux cookies et interdire leur envoi en même temps que les requêtes lancées à partir de sites Web tiers avec SameSite=Strict. Cela est utile lorsque vous avez des cookies liés à des fonctionnalités qui sont toujours derrière une navigation initiale, comme la modification d'un mot de passe ou la réalisation d'un achat.

La recette

Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Strict;