Cookie-Header-Parser

Der Cookie Header Parser dekodiert vom Browser gesendete Cookie-Header und vom Server gesendete Set-Cookie-Header in strukturierte, lesbare Formate und extrahiert Cookie-Namen, Werte und Sicherheitsattribute wie HttpOnly, Secure, SameSite, Ablaufdatum, Domain-Geltungsbereich und Pfad. Fügen Sie einen Header wie session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Strict ein und erhalten Sie eine klare Aufschlüsselung jedes Attributs mit Erklärungen, was jedes einzelne bewirkt.

HTTP-Cookies verstehen

Cookies sind der primäre Mechanismus des Webs zur Zustandserhaltung zwischen Anfragen. HTTP selbst ist zustandslos -- jede Anfrage ist unabhängig, und der Server hat keine eingebaute Möglichkeit sich zu merken, dass zwei Anfragen vom selben Benutzer stammen. Cookies lösen dies, indem sie dem Server erlauben, ein kleines Datenstück im Browser zu speichern, das der Browser dann mit jeder nachfolgenden Anfrage zurücksendet. So funktionieren Login-Sessions, so bleiben Warenkörbe über Seitenladevorgänge hinweg erhalten, und so merken sich Websites Ihre Spracheinstellungen.

Der Cookie-Lebenszyklus beginnt, wenn ein Server einen Set-Cookie-Header in einer HTTP-Antwort enthält. Dieser Header enthält den Namen und Wert des Cookies sowie optionale Attribute, die seine Lebensdauer, seinen Geltungsbereich und seine Sicherheitseigenschaften steuern. Der Browser speichert das Cookie und sendet es im Cookie-Header zukünftiger Anfragen an diese Domain mit. Ein einzelner Set-Cookie-Header setzt ein Cookie, aber ein einzelner Cookie-Header kann viele Cookies enthalten, getrennt durch Semikolons.

Was Cookies kompliziert macht, ist die Anzahl der Attribute, die ihr Verhalten beeinflussen. Die Attribute Domain und Path steuern, welche URLs das Cookie erhalten. Das Secure-Flag beschränkt die Übertragung auf HTTPS. Das HttpOnly-Flag verhindert, dass JavaScript das Cookie lesen kann, und schützt so vor Cross-Site-Scripting (XSS)-Angriffen. Das SameSite-Attribut steuert, ob das Cookie bei Cross-Origin-Anfragen gesendet wird, was die primäre Verteidigung gegen Cross-Site Request Forgery (CSRF) darstellt. Diese Attribute richtig zu setzen ist sowohl für die Funktionalität als auch für die Sicherheit entscheidend, und dieser Parser hilft Ihnen bei der Überprüfung, indem er jedes Attribut mit einer verständlichen Erklärung seiner Funktion anzeigt.

So parsen Sie einen Cookie-Header

1. Fügen Sie einen Cookie- oder Set-Cookie-Header-Wert in das Eingabefeld ein.
2. Wählen Sie den Header-Typ (Cookie für Request-Header, Set-Cookie für Response-Header).
3. Klicken Sie auf Parsen, um alle Cookies und ihre Attribute in eine strukturierte Ansicht zu extrahieren.
4. Überprüfen Sie die dekodierten Werte, Attributerklärungen und eventuelle Sicherheitsempfehlungen.

Beispiele zum Cookie-Header-Parsing

Parsing eines Browser-Cookie-Headers

Eingabe (Cookie-Header):

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

Geparste Ausgabe:

Parsing eines Set-Cookie-Response-Headers

Eingabe (Set-Cookie-Header):

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

Geparste Ausgabe:

Wann den Cookie Header Parser verwenden

• Debugging von Authentifizierungsproblemen -- Session-Cookies überprüfen, ob sie korrekt mit den richtigen Domain-, Pfad- und Ablaufwerten gesetzt werden.
• Cookie-Sicherheits-Audit -- prüfen, ob Session-Cookies die Flags HttpOnly, Secure und SameSite gesetzt haben, um XSS- und CSRF-Angriffe zu verhindern.
• Analyse von Drittanbieter-Cookies -- Tracking-Cookies von Analytics-, Werbe- und Social-Media-Widgets identifizieren und ihren Geltungsbereich verstehen.
• Fehlerbehebung bei Cross-Domain-Cookies -- Domain- und SameSite-Einstellungen überprüfen, wenn Cookies bei Cross-Origin-Anfragen nicht gesendet werden.
• Compliance-Überprüfung -- alle Cookies, die eine Website setzt, ihre Zwecke und ihre Lebensdauer für DSGVO- oder CCPA-Dokumentation inventarisieren.
• Incident Response -- bei einem Sicherheitsvorfall schnell alle Cookies parsen, um Session-Tokens, ihren Geltungsbereich und ob sie ordnungsgemäß gesichert sind, zu identifizieren.

Wie Cookie-Header funktionieren

Cookie vs. Set-Cookie

Diese beiden Header dienen den entgegengesetzten Richtungen des HTTP-Cookie-Flusses:

• Set-Cookie wird vom Server in einer Antwort gesendet, um ein Cookie im Browser zu erstellen oder zu aktualisieren. Jeder Set-Cookie-Header setzt ein Cookie mit seinen Attributen.
• Cookie wird vom Browser in einer Anfrage gesendet und enthält alle Cookies, die zur Domain und zum Pfad der aktuellen URL passen. Mehrere Cookies werden durch Semikolons getrennt.

Cookie-Attribut-Referenz

SameSite-Attributwerte

• Strict -- Cookie wird niemals bei Cross-Site-Anfragen gesendet. Am besten geeignet für sensitive Session-Cookies.
• Lax -- Cookie wird bei Top-Level-Navigation (Klick auf einen Link) gesendet, aber nicht bei Cross-Site-Unteranfragen (Bilder, Iframes, AJAX). Dies ist der Browser-Standard.
• None -- Cookie wird bei allen Cross-Site-Anfragen gesendet. Erfordert das Secure-Flag.

Cookie-Größen- und Anzahl-Limits

Browser erzwingen Limits für Cookies, die Sie kennen sollten:

Wenn diese Limits überschritten werden, verwirft der Browser still die ältesten Cookies. Wenn Ihre Anwendung plötzlich den Session-Zustand verliert, ist das Überschreiten von Cookie-Limits eine häufige, aber oft übersehene Ursache.

Praktische Tipps zur Cookie-Sicherheit

Die wichtigste Regel für Session-Cookies ist, immer alle drei Sicherheits-Flags zu setzen: HttpOnly, Secure und SameSite. Das HttpOnly-Flag verhindert, dass JavaScript über document.cookie auf das Cookie zugreift, sodass eine XSS-Schwachstelle Ihr Session-Token nicht stehlen kann. Das Secure-Flag stellt sicher, dass das Cookie niemals über unverschlüsseltes HTTP gesendet wird, selbst wenn ein Benutzer versehentlich die HTTP-Version Ihrer Website besucht. Und SameSite=Strict (oder mindestens Lax) verhindert, dass das Cookie bei Cross-Site-Anfragen gesendet wird, was die primäre Verteidigung gegen CSRF-Angriffe darstellt. Das Weglassen eines dieser Flags hinterlässt eine Lücke in Ihrer Sicherheit.

Cookie-Domain-Scoping ist ein weiterer Bereich, in dem Fehler häufig sind. Wenn Sie Domain=.example.com setzen (mit dem führenden Punkt), wird das Cookie an example.com und jede Subdomain gesendet -- einschließlich evil.example.com, falls ein Angreifer eine Subdomain registrieren kann. Für Session-Cookies ist es sicherer, das Domain-Attribut ganz wegzulassen, was das Cookie auf den exakten Origin beschränkt, der es gesetzt hat. Verwenden Sie Domain-Scoping nur, wenn Sie Cookies tatsächlich über Subdomains hinweg teilen müssen, z. B. für Single Sign-On zwischen app.example.com und api.example.com.

Achten Sie auf die Interaktion zwischen SameSite=None und dem Secure-Flag. Moderne Browser erfordern Secure, wenn SameSite=None gesetzt ist -- wenn Sie Secure weglassen, wird das Cookie still abgelehnt. Diese Anforderung existiert, weil SameSite=None dem Browser sagt, das Cookie bei Cross-Site-Anfragen zu senden, und dies über unverschlüsseltes HTTP würde das Cookie Netzwerk-Abhörern preisgeben. Wenn Ihr Drittanbieter-Cookie still verworfen wird, prüfen Sie, ob beide Attribute vorhanden sind.

Häufig gestellte Fragen

Warum hat mein Set-Cookie-Header keine Wirkung?

Häufige Ursachen sind: fehlendes Secure-Flag bei Verwendung von SameSite=None, Setzen von Domain auf eine andere Domain als den Response-Origin, Blockierung von Drittanbieter-Cookies durch den Browser oder Path auf einen Pfad gesetzt, der nicht mit der aktuellen Seite übereinstimmt.

Was ist der Unterschied zwischen Expires und Max-Age?

Expires verwendet ein absolutes Datum (Thu, 01 Jan 2026 00:00:00 GMT), während Max-Age Sekunden ab jetzt angibt (3600 = 1 Stunde). Wenn beide vorhanden sind, hat Max-Age Vorrang. Wenn keines gesetzt ist, ist das Cookie ein Session-Cookie und wird beim Schließen des Browsers gelöscht.

Wie kann ich erkennen, ob ein Cookie ein Tracking-Cookie ist?

Häufige Indikatoren sind: Namen, die mit _ga, _gid (Google Analytics), _fbp, _fbc (Facebook) oder _uet (Bing) beginnen. Cookies mit Domain auf einer Drittanbieter-Domain und langen Max-Age-Werten (oft 1-2 Jahre) sind typischerweise Tracking-Cookies.

Warum werden meine Cookies bei Cross-Origin-API-Anfragen nicht gesendet?

Cross-Origin-Anfragen erfordern eine spezifische Konfiguration sowohl auf Client- als auch auf Serverseite. Der Client muss credentials: 'include' in den Fetch-Optionen setzen, und der Server muss mit Access-Control-Allow-Credentials: true und einem spezifischen Origin (nicht *) in Access-Control-Allow-Origin antworten. Das Cookie benötigt außerdem SameSite=None; Secure, um cross-origin gesendet zu werden.

Was passiert, wenn das Cookie-Limit eines Browsers erreicht wird?

Browser entfernen still die ältesten oder am wenigsten kürzlich verwendeten Cookies, um Platz für neue zu schaffen. Es gibt keine Fehlermeldung oder Warnung. Wenn Ihre Anwendung auf viele Cookies angewiesen ist, sollten Sie in Betracht ziehen, sie in ein einzelnes JSON-kodiertes Cookie zu konsolidieren oder den Zustand auf serverseitige Sessions zu verlagern.

Wie funktionieren Cookie-Präfixe wie __Secure- und __Host-?

Dies sind Cookie-Namenspräfixe, die zusätzliche Sicherheitsanforderungen erzwingen. Ein Cookie namens __Secure-session muss das Secure-Flag haben. Ein Cookie namens __Host-session muss sowohl Secure als auch Path=/ haben und darf kein Domain-Attribut haben. Diese Präfixe bieten Defense-in-Depth gegen Cookie-Manipulationsangriffe.

Verwandte Tools

• HTTP Header Formatter - HTTP-Header einschließlich Set-Cookie parsen und formatieren
• CORS Header Explainer - CORS-Header verstehen, die die Cookie-Übertragung bei Cross-Origin-Anfragen beeinflussen
• HTTP Status Code Lookup - Statuscodes für Antworten nachschlagen, die Cookies setzen
• User-Agent Parser - User-Agent-Strings parsen, um zu verstehen, welcher Browser die Cookies gesendet hat
• curl Command Builder - curl-Befehle mit Cookie-Headern zum Testen erstellen