Analyseur de cookies HTTP
Analyse les chaînes d'en-tête HTTP Set-Cookie en champs structurés : nom, valeur, domaine, chemin, expiration, attributs Secure, HttpOnly et SameSite.
Load sample
Comment utiliser Analyseur de cookies HTTP
- 1Collez une chaîne d'en-tête Set-Cookie dans l'analyseur.
- 2Voyez chaque attribut détaillé (nom, valeur, domaine, etc.).
- 3Vérifiez les drapeaux de sécurité comme HttpOnly, Secure et SameSite.
- 4Comprenez l'expiration et la portée du cookie.
ZenovayAnalytics
Voyez qui est sur votre site en ce moment.
- Suivi des visiteurs en temps réel
- Vie privée d'abord, sans bandeau cookies
- Installé en deux minutes
Outils connexes
Formateur et Validateur JSON
Formatez, validez et embellissez les données JSON avec la coloration syntaxique et la détection d'erreurs.Décodeur JWT
Décodez et inspectez les jetons JWT. Consultez l'en-tête, la charge utile et vérifiez les signatures.Encodeur/Décodeur Base64
Encodez du texte en Base64 ou décodez Base64 en texte. Supporte UTF-8 et les données binaires.Encodage / Décodage URL
Encodez ou décodez les composants URL. Traitez les caractères spéciaux, les chaînes de requête et les URL complètes.Questions fréquemment posées
Qu'est-ce qu'un en-tête Set-Cookie ?▾
L'en-tête de réponse HTTP Set-Cookie est utilisé par un serveur pour envoyer un cookie au navigateur de l'utilisateur. Format : Set-Cookie: name=value; Path=/; Domain=example.com; Expires=Thu, 01 Jan 2026 00:00:00 GMT; HttpOnly; Secure; SameSite=Strict. Le navigateur stocke le cookie et le renvoie avec les requêtes suivantes vers les domaines et chemins correspondants via l'en-tête de requête Cookie:.
Que signifie HttpOnly ?▾
Le flag HttpOnly empêche JavaScript d'accéder au cookie via document.cookie. Cela protège contre les attaques XSS (cross-site scripting) qui tentent de voler les cookies de session. Les cookies de session authentifiés doivent toujours avoir HttpOnly défini. Remarque : HttpOnly n'empêche pas le cookie d'être envoyé avec les requêtes — il empêche seulement l'accès par script côté client.
Que signifie Secure pour les cookies ?▾
Le flag Secure garantit que le cookie n'est envoyé que sur les connexions HTTPS. Sans Secure, le cookie est envoyé sur HTTP brut, où il peut être intercepté par des attaquants réseau (attaques MITM). Tous les cookies contenant des données sensibles (tokens de session, authentification) doivent avoir Secure défini. Secure n'a aucun effet sur localhost.
Qu'est-ce que SameSite ?▾
SameSite contrôle quand les cookies sont envoyés avec les requêtes cross-site. Strict : cookie envoyé uniquement pour les requêtes same-site (plus sécurisé, casse les flux OAuth). Lax : cookie envoyé pour les requêtes same-site et les navigations top-level cross-site (GET uniquement) — la valeur par défaut dans les navigateurs modernes. None : cookie envoyé pour toutes les requêtes cross-site — nécessite le flag Secure. SameSite=None est requis pour les cookies tiers (analytics, contenu intégré).
Qu'est-ce que le préfixage de cookie (__Secure- et __Host-) ?▾
Préfixe __Secure- : le cookie doit avoir le flag Secure et être défini à partir de HTTPS. Préfixe __Host- : le cookie doit avoir le flag Secure, aucun attribut Domain, et Path=/. Le préfixe Host est plus strict et empêche le détournement de cookies de sous-domaine. Ces préfixes sont appliqués par le navigateur — un serveur ne peut pas les remplacer. Utilisez __Host- pour les cookies de session les plus sécurisés quand aucun partage de sous-domaine n'est nécessaire.