Découvrez comment définir des cookies propriétaires pour garantir la sécurité, la compatibilité avec plusieurs navigateurs et réduire les risques de dysfonctionnement une fois les cookies tiers supprimés.
Les cookies peuvent être propriétaires ou tiers selon le contexte de l'utilisateur, selon le site sur lequel il se trouve à ce moment-là. Si le schéma et le domaine enregistrables du cookie correspondent à la page de premier niveau actuelle, c'est-à-dire aux éléments affichés 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.
La recette des cookies propriétaires ?
Si le cookie que vous définissez n'est pas utilisé sur plusieurs sites (par exemple, pour gérer les sessions sur votre site et 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 les sites, accessibles via JavaScript et envoyés via des connexions HTTP, ce qui présente certains risques en termes de confidentialité et de sécurité. Nous nous efforçons 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 recommandée, 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 solide que vous pourrez ajuster pour n'ouvrir des autorisations qu'en cas de nécessité. Cet article aborde é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;
Host
est un préfixe facultatif qui rend certains attributs obligatoires et en interdit d'autres:
Secure
doit être présentDomain
doit être omisPath
doit être/
Avec Host
ajouté, vous pouvez compter sur le navigateur pour vérifier si ces attributs sont définis conformément aux règles __Host
et refuser le cookie dans le cas contraire.
Secure
protège les cookies contre le vol sur les réseaux non sécurisés, car il n'autorise l'envoi de cookies que via des connexions HTTPS. Si vous n'avez pas entièrement migré votre site vers HTTPS, faites de cette migration une priorité.
L'attribut Domain
spécifie les hôtes qui peuvent recevoir un cookie. Si vous ne l'indiquez pas, le cookie sera limité à l'hôte actuel du document, à l'exclusion des sous-domaines: le cookie de example.com
sera envoyé à chaque requête envoyée à example.com
, mais pas à images.example.com
. Si différentes applications s'exécutent sur différents sous-domaines, vous réduisez le risque qu'un domaine compromis permette l'accès 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 de 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
reçoive des valeurs différentes de example.com/b
.
L'attribut HttpOnly
ajoute une protection contre les scripts tiers malveillants sur vos sites en restreignant l'accès JavaScript. Elle permet d'envoyer un cookie uniquement dans les en-têtes de requête et rend ces cookies indisponibles pour JavaScript à l'aide de document.cookie
.
Max-Age
limite la durée de vie des cookies, car les sessions de navigateur peuvent durer assez longtemps et vous ne voulez pas que les cookies obsolètes soient perdus indéfiniment. Il est adapté aux cookies à court terme, comme les sessions utilisateur, ou même aux cookies plus courts, comme les jetons d'envoi de formulaire. Max-Age
est défini en secondes. Dans l'exemple précédent, il est défini sur 7776 000 secondes, soit 90 jours. Il s'agit d'une valeur par défaut raisonnable, que vous pouvez modifier selon votre cas d'utilisation.
SameSite=Lax
limite l'envoi du cookie aux requêtes au même site. C'est-à-dire lorsque la requête correspond au contexte de navigation actuel, c'est-à-dire au site de premier niveau actuellement consulté par l'utilisateur, qui s'affiche dans sa barre d'emplacement. SameSite=Lax
est l'option par défaut dans les navigateurs récents, mais il est recommandé de la spécifier pour assurer la compatibilité avec les navigateurs qui peuvent avoir des valeurs par défaut différentes. En marquant explicitement le cookie comme étant lié au même site, vous le limitez à vos contextes propriétaires, et vous ne devriez pas avoir à le modifier lorsque les cookies tiers disparaissent.
Pour en savoir plus sur les différents attributs de cookies, consultez la documentation Set-Cookie
sur MDN.
Recette des cookies propriétaires pour les sites avec des sous-domaines
Si votre site comporte des sous-domaines et que vous souhaitez lancer une session sur chacun d'eux, le préfixe Host
peut être trop restrictif. Par exemple, news.site
peut disposer de sous-domaines pour des sujets tels que finance.news.site
et sport.news.site
, et vous pouvez choisir d'avoir une session utilisateur sur chacun d'eux. 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;
Secure
est un préfixe facultatif qui définit moins d'exigences que Host
: il requiert uniquement que le cookie soit défini avec l'attribut Secure
.
Restriction de l'accès aux cookies propriétaires pour les requêtes lancées à partir de sites Web tiers
Bien que les cookies SameSite=Lax
ne soient pas envoyés lors de sous-requêtes intersites (par exemple, lors du chargement d'images intégrées ou d'iFrames 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 avec les requêtes effectuées à partir de sites Web tiers à l'aide de SameSite=Strict
. Cela est utile lorsque vous avez des cookies liés à une fonctionnalité qui est toujours liée à une navigation initiale, telle qu'un changement de mot de passe ou un achat.
La recette
Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Strict;