Analyseur d’en-tête Cookie

Le Cookie Header Parser décode les en-têtes Cookie envoyés par le navigateur et les en-têtes Set-Cookie envoyés par le serveur en formats structurés et lisibles, en extrayant les noms de cookies, les valeurs et les attributs de sécurité tels que HttpOnly, Secure, SameSite, l'expiration, la portée du domaine et le chemin. Collez un en-tête comme session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Strict et obtenez un détail clair de chaque attribut avec des explications sur son rôle.

Comprendre les cookies HTTP

Les cookies sont le mécanisme principal du web pour maintenir l'état entre les requêtes. HTTP est lui-même sans état -- chaque requête est indépendante, et le serveur n'a aucun moyen intégré de se souvenir que deux requêtes proviennent du même utilisateur. Les cookies résolvent ce problème en permettant au serveur de stocker un petit morceau de données dans le navigateur, que celui-ci renvoie ensuite avec chaque requête ultérieure. C'est ainsi que fonctionnent les sessions de connexion, que les paniers d'achat persistent entre les chargements de page, et que les sites mémorisent vos préférences linguistiques.

Le cycle de vie d'un cookie commence lorsqu'un serveur inclut un en-tête Set-Cookie dans une réponse HTTP. Cet en-tête contient le nom et la valeur du cookie, plus des attributs optionnels qui contrôlent sa durée de vie, sa portée et ses propriétés de sécurité. Le navigateur stocke le cookie et l'inclut dans l'en-tête Cookie des futures requêtes vers ce domaine. Un seul en-tête Set-Cookie définit un cookie, mais un seul en-tête Cookie peut transporter de nombreux cookies, séparés par des points-virgules.

Ce qui rend les cookies complexes, c'est le nombre d'attributs qui affectent leur comportement. Les attributs Domain et Path contrôlent quelles URL reçoivent le cookie. Le flag Secure restreint la transmission au HTTPS. Le flag HttpOnly empêche JavaScript de lire le cookie, protégeant contre les attaques de type cross-site scripting (XSS). L'attribut SameSite contrôle si le cookie est envoyé avec les requêtes cross-origin, ce qui constitue la défense principale contre la falsification de requêtes cross-site (CSRF). Configurer correctement ces attributs est crucial tant pour la fonctionnalité que pour la sécurité, et ce parseur vous aide à les vérifier en affichant chaque attribut avec une explication en langage clair de son rôle.

Comment analyser un en-tête Cookie

1. Collez la valeur d'un en-tête Cookie ou Set-Cookie dans le champ de saisie.
2. Sélectionnez le type d'en-tête (Cookie pour les en-têtes de requête, Set-Cookie pour les en-têtes de réponse).
3. Cliquez sur Analyser pour extraire tous les cookies et leurs attributs dans une vue structurée.
4. Consultez les valeurs décodées, les explications des attributs et les recommandations de sécurité éventuelles.

Exemples d'analyse d'en-têtes Cookie

Analyse d'un en-tête Cookie de navigateur

Entrée (en-tête Cookie) :

session_id=abc123def456; theme=dark; lang=en-US; _ga=GA1.2.123456789.1609459200

Résultat de l'analyse :

Analyse d'un en-tête de réponse Set-Cookie

Entrée (en-tête Set-Cookie) :

session_id=abc123def456; Path=/; Domain=.example.com; Expires=Thu, 01 Jan 2026 00:00:00 GMT; HttpOnly; Secure; SameSite=Strict

Résultat de l'analyse :

Quand utiliser le Cookie Header Parser

• Débogage de problèmes d'authentification -- Inspectez les cookies de session pour vérifier qu'ils sont correctement définis avec les bonnes valeurs de domaine, chemin et expiration.
• Audit de sécurité des cookies -- Vérifiez que les cookies de session ont les flags HttpOnly, Secure et SameSite activés pour prévenir les attaques XSS et CSRF.
• Analyse des cookies tiers -- Identifiez les cookies de tracking provenant de widgets d'analytics, de publicité et de réseaux sociaux, et comprenez leur portée.
• Résolution de problèmes de cookies cross-domain -- Vérifiez les paramètres Domain et SameSite lorsque les cookies ne sont pas envoyés dans les requêtes cross-origin.
• Revue de conformité -- Inventoriez tous les cookies qu'un site définit, leurs finalités et leurs durées de vie pour la documentation RGPD ou CCPA.
• Réponse aux incidents -- Lors d'un incident de sécurité, analysez rapidement tous les cookies pour identifier les tokens de session, leur portée et s'ils sont correctement sécurisés.

Comment fonctionnent les en-têtes Cookie

Cookie vs. Set-Cookie

Ces deux en-têtes servent des directions opposées du flux de cookies HTTP :

• Set-Cookie est envoyé par le serveur dans une réponse pour créer ou mettre à jour un cookie dans le navigateur. Chaque en-tête Set-Cookie définit un cookie avec ses attributs.
• Cookie est envoyé par le navigateur dans une requête, contenant tous les cookies qui correspondent au domaine et au chemin de l'URL courante. Les cookies multiples sont séparés par des points-virgules.

Référence des attributs de cookies

Valeurs de l'attribut SameSite

• Strict -- Le cookie n'est jamais envoyé lors des requêtes cross-site. Idéal pour les cookies de session sensibles.
• Lax -- Le cookie est envoyé lors de la navigation de premier niveau (clic sur un lien) mais pas lors des sous-requêtes cross-site (images, iframes, AJAX). C'est le comportement par défaut du navigateur.
• None -- Le cookie est envoyé pour toutes les requêtes cross-site. Nécessite le flag Secure.

Limites de taille et de nombre des cookies

Les navigateurs imposent des limites sur les cookies dont vous devez être conscient :

Lorsque ces limites sont dépassées, les navigateurs suppriment silencieusement les cookies les plus anciens. Si votre application perd soudainement son état de session, le dépassement des limites de cookies est une cause courante mais souvent négligée.

Conseils pratiques pour la sécurité des cookies

La règle la plus importante pour les cookies de session est de toujours définir les trois flags de sécurité : HttpOnly, Secure et SameSite. Le flag HttpOnly empêche JavaScript d'accéder au cookie via document.cookie, ce qui signifie qu'une vulnérabilité XSS ne peut pas voler votre token de session. Le flag Secure garantit que le cookie n'est jamais envoyé via HTTP non chiffré, même si un utilisateur visite accidentellement la version HTTP de votre site. Et SameSite=Strict (ou au minimum Lax) empêche le cookie d'être envoyé dans les requêtes cross-site, ce qui constitue la défense principale contre les attaques CSRF. Omettre un seul de ces flags laisse une brèche dans votre posture de sécurité.

La portée du domaine des cookies est un autre domaine où les erreurs sont fréquentes. Si vous définissez Domain=.example.com (avec le point initial), le cookie est envoyé à example.com et à chaque sous-domaine -- y compris evil.example.com si un attaquant peut enregistrer un sous-domaine. Pour les cookies de session, il est plus sûr d'omettre entièrement l'attribut Domain, ce qui restreint le cookie à l'origine exacte qui l'a défini. N'utilisez la portée de domaine que lorsque vous avez véritablement besoin de partager des cookies entre sous-domaines, comme pour l'authentification unique entre app.example.com et api.example.com.

Faites attention à l'interaction entre SameSite=None et le flag Secure. Les navigateurs modernes exigent Secure lorsque SameSite=None est défini -- si vous omettez Secure, le cookie est silencieusement rejeté. Cette exigence existe parce que SameSite=None indique au navigateur d'envoyer le cookie lors des requêtes cross-site, et le faire via HTTP non chiffré exposerait le cookie aux écoutes réseau. Si votre cookie tiers est silencieusement ignoré, vérifiez que les deux attributs sont présents.

Questions fréquentes

Pourquoi mon en-tête Set-Cookie n'a-t-il aucun effet ?

Les causes courantes incluent : flag Secure manquant lors de l'utilisation de SameSite=None, définition du Domain sur un domaine différent de l'origine de la réponse, blocage des cookies tiers par le navigateur, ou Path défini sur un chemin qui ne correspond pas à la page actuelle.

Quelle est la différence entre Expires et Max-Age ?

Expires utilise une date absolue (Thu, 01 Jan 2026 00:00:00 GMT), tandis que Max-Age spécifie des secondes à partir de maintenant (3600 = 1 heure). Lorsque les deux sont présents, Max-Age est prioritaire. Si aucun n'est défini, le cookie est un cookie de session et est supprimé à la fermeture du navigateur.

Comment savoir si un cookie est un cookie de tracking ?

Les indicateurs courants incluent : noms commençant par _ga, _gid (Google Analytics), _fbp, _fbc (Facebook), ou _uet (Bing). Les cookies avec un Domain défini sur un domaine tiers et de longues valeurs Max-Age (souvent 1 à 2 ans) sont généralement des cookies de tracking.

Pourquoi mes cookies ne sont-ils pas envoyés dans les requêtes API cross-origin ?

Les requêtes cross-origin nécessitent une configuration spécifique côté client et serveur. Le client doit définir credentials: 'include' dans les options fetch, et le serveur doit répondre avec Access-Control-Allow-Credentials: true et une origine spécifique (pas *) dans Access-Control-Allow-Origin. Le cookie doit également avoir SameSite=None; Secure pour être envoyé en cross-origin.

Que se passe-t-il lorsque la limite de cookies d'un navigateur est atteinte ?

Les navigateurs expulsent silencieusement les cookies les plus anciens ou les moins récemment utilisés pour faire de la place aux nouveaux. Il n'y a ni erreur ni avertissement. Si votre application repose sur de nombreux cookies, envisagez de les consolider en un seul cookie encodé en JSON ou de déplacer l'état vers des sessions côté serveur.

Comment fonctionnent les préfixes de cookies comme __Secure- et __Host- ?

Ce sont des préfixes de nom de cookie qui imposent des exigences de sécurité supplémentaires. Un cookie nommé __Secure-session doit avoir le flag Secure. Un cookie nommé __Host-session doit avoir à la fois Secure et Path=/, et ne doit pas avoir d'attribut Domain. Ces préfixes offrent une défense en profondeur contre les attaques de manipulation de cookies.

Outils associés

• HTTP Header Formatter - Analyser et formater les en-têtes HTTP, y compris Set-Cookie
• CORS Header Explainer - Comprendre les en-têtes CORS qui affectent la transmission des cookies dans les requêtes cross-origin
• HTTP Status Code Lookup - Rechercher les codes de statut des réponses qui définissent des cookies
• User-Agent Parser - Analyser les chaînes User-Agent pour comprendre quel navigateur a envoyé les cookies
• curl Command Builder - Construire des commandes curl avec des en-têtes cookie pour les tests