ZenovayTools

HTTP-Cookie-Parser

Analysiert HTTP Set-Cookie-Header-Strings in strukturierte Felder: Name, Wert, Domain, Pfad, Verfallsdatum, Secure, HttpOnly und SameSite-Attribute.

Load sample

So verwenden Sie HTTP-Cookie-Parser

  1. 1Fügen Sie eine Set-Cookie-Header-String in den Parser ein.
  2. 2Sehen Sie jedes Attribut aufgeschlüsselt (Name, Wert, Domain usw.).
  3. 3Überprüfen Sie Sicherheitsflags wie HttpOnly, Secure und SameSite.
  4. 4Verstehen Sie das Cookie-Verfallsdatum und den Gültigkeitsbereich.
ZenovayAnalytics

Sehen Sie, wer gerade auf Ihrer Seite ist.

  • Besucher-Tracking in Echtzeit
  • Datenschutz zuerst, kein Cookie-Banner
  • In zwei Minuten eingerichtet
Zenovay entdecken

Verwandte Tools

JSON-Formatter und Validator
Formatieren, validieren und verschönern Sie JSON-Daten mit Syntaxhervorhebung und Fehlererkennung.
JWT-Decoder
Dekodieren und inspizieren Sie JWT-Token. Zeigen Sie Header, Payload und überprüfen Sie Signaturen.
Base64 Encode/Decode
Kodieren Sie Text in Base64 oder dekodieren Sie Base64 zurück in Text. Unterstützt UTF-8 und Binärdaten.
URL Codierungstool
Codieren oder decodieren Sie URL-Komponenten. Verarbeiten Sie Sonderzeichen, Abfragezeichenfolgen und vollständige URLs.

Häufig gestellte Fragen

Was ist ein Set-Cookie-Header?▾
Der HTTP-Response-Header Set-Cookie wird vom Server verwendet, um dem Browser des Benutzers ein Cookie zu senden. Format: Set-Cookie: name=value; Path=/; Domain=example.com; Expires=Thu, 01 Jan 2026 00:00:00 GMT; HttpOnly; Secure; SameSite=Strict. Der Browser speichert das Cookie und sendet es mit nachfolgenden Anfragen an übereinstimmende Domains und Pfade über den Cookie-Request-Header.
Was bedeutet HttpOnly?▾
Das HttpOnly-Flag verhindert, dass JavaScript auf das Cookie über document.cookie zugreift. Dies schützt vor XSS-Angriffen (Cross-Site Scripting), die versuchen, Session-Cookies zu stehlen. Authentifizierte Session-Cookies sollten immer HttpOnly gesetzt haben. Hinweis: HttpOnly verhindert nicht, dass das Cookie mit Anfragen gesendet wird – es verhindert nur den Zugriff durch Client-seitiges Skript.
Was bedeutet Secure für Cookies?▾
Das Secure-Flag stellt sicher, dass das Cookie nur über HTTPS-Verbindungen gesendet wird. Ohne Secure wird das Cookie über unverschlüsseltes HTTP gesendet, wo es von Netzwerk-Angreifern abgefangen werden kann (MITM-Angriffe). Alle Cookies mit sensiblen Daten (Session-Tokens, Authentifizierung) sollten Secure gesetzt haben. Secure hat keine Auswirkung auf localhost.
Was ist SameSite?▾
SameSite steuert, wann Cookies mit Cross-Site-Anfragen gesendet werden. Strict: Cookie wird nur für Same-Site-Anfragen gesendet (am sichersten, unterbricht OAuth-Flows). Lax: Cookie wird für Same-Site- und Top-Level-Cross-Site-Navigationen gesendet (nur GET) – der Standard in modernen Browsern. None: Cookie wird für alle Cross-Site-Anfragen gesendet – erfordert das Secure-Flag. SameSite=None ist erforderlich für Third-Party-Cookies (Analytics, eingebetteter Inhalt).
Was ist Cookie-Präfixing (__Secure- und __Host-)?▾
__Secure--Präfix: Cookie muss das Secure-Flag haben und von HTTPS gesetzt werden. __Host--Präfix: Cookie muss das Secure-Flag haben, kein Domain-Attribut und Path=/ haben. Das Host-Präfix ist strikter und verhindert Cookie-Hijacking durch Subdomains. Diese Präfixe werden vom Browser erzwungen – ein Server kann sie nicht außer Kraft setzen. Verwenden Sie __Host- für die sichersten Session-Cookies, wenn keine Subdomain-Freigabe erforderlich ist.