Pourquoi l'en-tête Set-Cookie a-t-il été défini avec succès mais le navigateur n'a-t-il pas enregistré mon cookie ?
C'est le problème le plus courant. Les navigateurs ne signalent pas activement les erreurs ; ils rejettent silencieusement les cookies non conformes. Les causes courantes incluent : SameSite=None sans Secure, cookies Secure définis sur des pages HTTP (exception localhost), préfixes __Host-/__Secure- ne satisfaisant pas les contraintes, incompatibilité Domain/Path, dépassement de la limite de taille de 4 Ko, Max-Age étant 0 ou négatif. Nous recommandons d'abord de coller vos en-têtes Set-Cookie dans cet outil pour vérifier les badges d'avertissement et identifier la cause spécifique, puis d'ouvrir Chrome DevTools → Application → Cookies, de chercher un triangle d'avertissement jaune sous le domaine correspondant et de le survoler pour afficher la raison exacte du rejet.
Quelle est exactement la différence entre Strict, Lax et None pour SameSite ? Quand utiliser lequel ?
Strict n'autorise absolument pas l'envoi intersite — le plus sûr, mais les utilisateurs cliquant depuis des liens externes semblent déconnectés, adapté aux cookies d'opérations sensibles comme les paiements/changements de mot de passe. Lax est la valeur par défaut dans Chrome 80+, autorisant l'envoi de cookies lorsque les utilisateurs naviguent vers votre site via GET de niveau supérieur depuis des liens externes (en cliquant sur un lien externe vers votre site), mais pas pour les sous-ressources comme iframe/img/script/XHR/formulaires POST — valeur recommandée pour la plupart des scénarios. None autorise l'envoi dans tous les scénarios intersites (pour l'authentification unique SSO, les iframes intégrés tiers, les appels API intersites) mais doit être associé à Secure, sinon le navigateur le rejette purement et simplement.
Pourquoi SameSite=None doit-il être associé à Secure ?
C'est une règle que Chrome applique depuis la version 80 (février 2020), et Firefox, Edge et Safari ont tous emboîté le pas. Comme SameSite=None autorise explicitement l'envoi intersite de cookies, les attaquants peuvent plus facilement lancer des CSRF ou écouter dans des scénarios intersites, il doit donc être associé à Secure (transmission chiffrée HTTPS) pour atténuer les risques. Si votre cookie SameSite=None est défini sur HTTP, le navigateur le rejette simplement sans le stocker. Cet outil détecte les combinaisons SameSite=None-sans-Secure et les signale par des avertissements rouges.
Dois-je utiliser Max-Age ou Expires ? Quelle est la différence ?
Préférez Max-Age. Max-Age est un temps relatif (expire après N secondes), ne dépend pas de l'horloge client et le navigateur commence le compte à rebours à la réception ; Expires est un point dans le temps absolu, dépendant de l'heure locale de l'ordinateur de l'utilisateur (si un utilisateur règle son horloge sur 1970, le cookie expire immédiatement). Lorsque les deux sont présents, Max-Age a priorité (spécifié explicitement par la RFC 6265). Si aucun des deux n'est défini, le cookie devient un « cookie de session » qui expire lorsque le navigateur est fermé. Cet outil invite lorsque Expires est défini sans Max-Age, recommandant d'ajouter Max-Age. Note : L'unité de Max-Age est la seconde, pas la milliseconde.
Quelle est la différence entre Path=/ et l'absence de définition de Path ?
Path détermine pour quelles requêtes de chemin URL le navigateur inclura ce cookie. Lorsque Path n'est pas défini, le navigateur utilise par défaut « le chemin de l'URL de réponse sans le dernier segment » — par exemple, lors de la définition d'un cookie depuis /api/user/login, le Path par défaut est /api/user/, donc les requêtes sous / et /order/ n'incluront pas ce cookie. Définir explicitement Path=/ rend le cookie actif sur l'ensemble du site. Notez que la correspondance de Path est une correspondance de préfixe — Path=/api correspond également à /api/, /api/user, /api/v2/abc, etc. Les cookies préfixés __Host- nécessitent Path=/.
Quelle est la différence entre un Domain avec un point en tête (comme .example.com) et sans point ?
Dans les navigateurs modernes (versions récentes de Chrome, Firefox, Edge, Safari), les deux sont équivalents — tous deux rendent le cookie valide pour example.com et tous ses sous-domaines (a.example.com, b.c.example.com). Le point en tête était une ancienne syntaxe de l'époque de la RFC 2109 ; la RFC 6265 spécifie explicitement d'ignorer les points en tête. Cependant, la forme sans point est recommandée pour la lisibilité. Cet outil signale les Domain avec un point en tête (pas une erreur, mais une notation historique héritée). Note : Lorsque Domain n'est pas défini, le cookie s'applique uniquement à l'hôte actuel (les sous-domaines ne le recevront pas) ; définir Domain le rend applicable aux sous-domaines.
Que sont les préfixes __Host- et __Secure- ? Puis-je les omettre ?
Ce sont des préfixes de sécurité de nom de cookie introduits dans la RFC 6265bis pour ajouter des contraintes strictes aux cookies à haute sécurité : lorsque les navigateurs voient qu'un nom de cookie commence par __Host-, ils imposent que Secure soit défini, que Path soit / et que Domain ne soit pas défini — si une condition n'est pas remplie, le stockage est purement et simplement rejeté ; le préfixe __Secure- nécessite que Secure soit défini, les autres attributs sont configurables. Les cookies fonctionnent également sans préfixes (la plupart des cookies n'utilisent pas de préfixes), mais __Host- est fortement recommandé pour les cookies à haute sécurité comme les identifiants de session et les jetons d'authentification, car il empêche les attaques par injection de cookies au niveau sous-domaine/chemin. Cet outil détecte automatiquement la conformité des deux types de préfixes.
Les cookies HttpOnly sont-ils vraiment sécurisés ? Empêchent-ils les XSS et CSRF ?
HttpOnly empêche JavaScript de lire les valeurs de cookie via document.cookie, ce qui en fait une ligne de défense importante pour l'<strong>atténuation du vol de session XSS</strong>, mais ce n'est pas une solution miracle : les attaquants XSS peuvent toujours initier des requêtes dans le navigateur de l'utilisateur (qui incluent automatiquement les cookies) pour effectuer des actions (c'est le domaine du CSRF) ; HttpOnly ne défend pas non plus contre les attaques CSRF (nécessite SameSite ou des jetons CSRF). Le trio complet HttpOnly+Secure+SameSite=Lax/Strict doit être utilisé ensemble pour atteindre un niveau de sécurité de base. Les cookies sensibles (session, JWT, access_token) doivent être HttpOnly ; ne les exposez pas au JS frontend sauf si nécessaire. Cet outil avertit sur les cookies sans HttpOnly.
Que sont les cookies Partitioned (CHIPS) ? Quand dois-je les utiliser ?
Partitioned est un nouvel attribut que Chrome a introduit en préparation de la suppression des cookies tiers, abréviation de Cookies Having Independent Partitioned State (CHIPS). Les cookies tiers traditionnels (comme ceux définis par les services de publicité/intégration sur plusieurs sites) sont partagés globalement et pouvaient être utilisés pour le suivi intersite des utilisateurs. Avec Partitioned ajouté, les navigateurs stockent ce cookie tiers séparément par site de niveau supérieur : le cookie tiers qu'un utilisateur voit sur le Site A est complètement indépendant de celui sur le Site B, sans partage d'identité intersite. Cas d'utilisation : composants vidéo/carte/paiement intégrés, plugins de chat tiers, iframes SSO intersites intégrés. Partitioned doit être utilisé avec Secure et est recommandé avec le préfixe __Host-.
Combien de données un seul cookie peut-il stocker ? Combien peut-on en placer par domaine ?
Selon la RFC 6265, les navigateurs doivent prendre en charge au moins 4096 octets par cookie (nom, valeur et attributs inclus). Les navigateurs majeurs (Chrome/Firefox/Safari/Edge) appliquent tous cette limite ; l'excédent est silencieusement tronqué ou supprimé. Les limites de nombre varient selon le navigateur : Chrome autorise ~180 par domaine, Firefox ~150, Safari ~600 (et est affecté par la politique de nettoyage de 7 jours d'ITP), après quoi les navigateurs évincents les cookies les plus anciens via une stratégie LRU. Nous recommandons que les cookies ne stockent que des identifiants de session — ne placez pas de gros blocs de données métier dans les cookies (stockez les données métier dans localStorage ou des sessions côté serveur).
L'outil prend-il en charge l'analyse de Set-Cookie copié directement depuis Chrome DevTools ? Dois-je supprimer les préfixes manuellement ?
Pris en charge entièrement — aucun traitement manuel nécessaire. Vous pouvez accéder à Chrome DevTools → panneau Network, cliquer sur la requête cible, faire un clic droit sur la valeur Set-Cookie dans la section Response Headers et copier directement (pour plusieurs lignes, Ctrl/⌘+clic pour une sélection multiple ou copier le bloc entier), puis coller dans la zone de saisie de cet outil. L'outil retire automatiquement le préfixe Set-Cookie: du début de chaque ligne (insensible à la casse), traite les espaces en début/fin de ligne, traite correctement les caractères spéciaux comme les virgules et les points-virgules dans les dates Expires et traite correctement les valeurs de cookie entre guillemets doubles.
Pourquoi les caractères chinois ou spéciaux dans les valeurs de cookie deviennent-ils sous forme %XX ?
La RFC 6265 exige que les valeurs de cookie n'utilisent qu'un sous-ensemble sécurisé du jeu de caractères ASCII et ne peuvent pas contenir directement de caractères chinois, espaces, virgules, points-virgules, etc. De nombreux frameworks côté serveur encodent automatiquement en URL (encodeURIComponent/encodage pour cent) les caractères non ASCII lors de la définition des cookies, par ex. « 你好 » est encodé en %E4%BD%A0%E5%A5%BD. Les navigateurs conservent également la forme encodée lors du renvoi. Lorsque cet outil détecte que des valeurs contiennent un encodage %XX, il affiche automatiquement le texte original décodé par decodeURIComponent à côté de la valeur brute avec une flèche verte pour faciliter la vérification du contenu réel.
Quelle est la différence entre Set-Cookie et l'en-tête de requête Cookie ?
Ce sont des en-têtes dans des directions complètement opposées : Set-Cookie est un en-tête de réponse (serveur → navigateur), n'apparaît que dans les réponses, peut apparaître plusieurs fois et définit à chaque fois un cookie avec des attributs complets (Secure/HttpOnly/Path/Domain/etc.) ; Cookie est un en-tête de requête (navigateur → serveur), n'apparaît qu'une seule fois par requête et contient des paires name=value plates (name1=v1; name2=v2) de tous les cookies correspondant à la portée, sans aucune information d'attribut. Cela signifie que les serveurs ne peuvent pas savoir à partir des requêtes si un cookie a HttpOnly ou Secure défini — les informations d'attribut ne sont conservées que par le navigateur lors du stockage local. Pour analyser les en-têtes de requête Cookie, utilisez l'<a href='/network/http-cookie-parser/'>analyseur d'en-tête de requête Cookie</a> associé.
Pourquoi mes cookies disparaissent-ils après quelques jours dans Safari ?
C'est le mécanisme d'Intelligent Tracking Prevention (ITP) de Safari qui est à l'œuvre. Depuis ITP 2.1, si un utilisateur n'interagit pas directement avec un domaine pendant 7 jours (c'est-à-dire n'a pas visité directement le site de ce domaine), Safari nettoie tous les cookies et données de site sous ce domaine, indépendamment de la durée définie pour Max-Age/Expires. Cela a le plus grand impact sur les services intégrés tiers, tandis que les cookies du site principal ne sont pas affectés tant que les utilisateurs continuent de visiter. De plus, les restrictions de Safari sur les cookies tiers sont plus strictes que celles de Chrome. Les solutions incluent : l'utilisation de l'attribut Partitioned, la demande d'autorisations via l'API Storage Access, ou l'actualisation des cookies lorsque les utilisateurs visitent le site principal. La section de dépannage de cet outil contient des conseils de débogage Safari plus détaillés.
L'outil prend-il en charge l'analyse en masse de plusieurs en-têtes Set-Cookie ? Le contenu des cookies est-il téléchargé sur des serveurs ?
L'analyse en masse est prise en charge. La zone de saisie prend en charge le collage d'un nombre quelconque d'en-têtes Set-Cookie multi-lignes (par exemple, coller un bloc d'en-tête de réponse entier en une fois). Chaque Set-Cookie est analysé avec une numérotation indépendante, avec plusieurs cartes d'attributs affichant leurs attributs et avertissements respectifs. Tous les processus d'analyse s'exécutent entièrement localement dans votre navigateur (traitement JavaScript frontend pur). Le contenu des cookies n'est jamais téléchargé sur aucun serveur, aucune requête réseau n'est effectuée, et les informations sensibles comme les sessions/tokens que vous collez ne quittent jamais votre ordinateur — utilisez-le en toute confiance.
