Cookie-Parser
Set-Cookie-Header und document.cookie-Zeichenketten in strukturierte Daten analysieren. Die gesamte Verarbeitung erfolgt in Ihrem Browser für maximale Sicherheit und Datenschutz.
0
Cookies insgesamt
0
Sichere Cookies
0
HttpOnly-Cookies
Analysierte Cookies
| Cookie-Name | Wert | Domäne | Pfad | Läuft ab | Max-Age | Flags |
|---|
Verwendung des Cookie-Parsers
Modus wählen
Wählen Sie den Set-Cookie-Header-Modus für HTTP-Header oder den document.cookie-Modus für Browser-Cookie-Zeichenketten
Daten einfügen
Fügen Sie Ihre Set-Cookie-Header (einen pro Zeile) oder eine document.cookie-Zeichenkette in das Eingabefeld ein
Ergebnisse prüfen
Analysierte Cookies in einer strukturierten Tabelle mit Statistiken zu Sicherheits-Flags anzeigen
Was sind HTTP-Cookies?
HTTP-Cookies sind kleine Datenpakete, die vom Browser im Auftrag von Websites gespeichert werden. Sie werden über den Set-Cookie-HTTP-Antwortheader gesendet und über den Cookie-Header an nachfolgende Anforderungen angehängt. Cookies werden zur Sitzungsverwaltung, Personalisierung und Nachverfolgung verwendet. Sicherheits-Flags wie HttpOnly, Secure und SameSite helfen, Cookies vor Cross-Site-Scripting (XSS)- und Cross-Site-Request-Forgery (CSRF)-Angriffen zu schützen.
HttpOnly
Verhindert den Zugriff clientseitiger Skripte auf den Cookie und mindert XSS-Angriffe
Sicher
Stellt sicher, dass der Cookie nur über HTTPS-Verbindungen gesendet wird
SameSite
Steuert das seitenübergreifende Cookie-Senden: Strict, Lax oder None zum Schutz vor CSRF-Angriffen
Häufig gestellte Fragen
Das Tool analysiert Set-Cookie-HTTP-Header und document.cookie-JavaScript-Zeichenketten. Mehrere Cookies können gleichzeitig analysiert werden.
Ja. HttpOnly, Secure, SameSite (Strict/Lax/None), Path und Domain-Attribute werden für jedes Cookie angezeigt.
Ja. Im Set-Cookie-Modus fügen Sie einen Header pro Zeile ein. Im document.cookie-Modus werden alle Cookies in der Zeichenkette analysiert.
SameSite=Strict sendet das Cookie nur bei Same-Site-Navigationen – voller CSRF-Schutz, aber kein Cookie bei eingehenden Links von außen. Lax (der Browser-Standard) erlaubt, dass Top-Level-GET-Navigationen das Cookie mitführen, wodurch Login-Sitzungen über externe Links weiterhin funktionieren, während die meisten CSRF-Angriffe blockiert werden. None hebt die Einschränkung auf, erfordert jedoch Secure, andernfalls verwerfen Browser das Cookie – genau diese Kombination benötigen Cross-Site-Iframes und Zahlungsabläufe.
Ein Cookie ohne Expires oder Max-Age ist ein Session-Cookie: Er existiert nur im Speicher und verschwindet mit der Browser-Sitzung (moderne Browser stellen ihn nach einem Absturz allerdings unter Umständen wieder her). Expires setzt eine absolute Frist, Max-Age eine relative in Sekunden – sind beide vorhanden, gewinnt Max-Age. Persistente Cookies sind der Grund, warum Remember-me-Logins und langlebige Analytics-IDs Neustarts überleben.
Es sind Garantien auf Namensebene, die Browser durchsetzen. __Secure- verlangt einen https-Ursprung und das Secure-Attribut. __Host- ist strenger: Secure, kein Domain-Attribut (host-only) und Path=/ – dadurch kann ein Cookie mit __Host--Präfix nicht von einer Subdomain überschrieben werden, was es an die exakte Site bindet. Browser ohne Unterstützung behandeln die Präfixe einfach als gewöhnliche Zeichen des Namens.
RFC 6265 verlangt von Browsern, mindestens 4096 Bytes pro Cookie und mindestens 50 Cookies pro Domain zu akzeptieren. Chrome begrenzt auf etwa 180 Cookies pro Domain und insgesamt einige Tausend; Safari ist in der Praxis strenger. Da Cookies bei jeder Anfrage an die Domain mitgeschickt werden, verlangsamt umfangreiche Cookie-Speicherung den Traffic messbar – der Grund, warum große Websites Zustände in localStorage oder serverseitige Sessions auslagern.
HttpOnly verbirgt das Cookie vor document.cookie in JavaScript, sodass injizierte XSS-Skripte es nicht lesen können – setzen Sie es bei Session-Cookies immer. Secure beschränkt die Übertragung auf HTTPS-Verbindungen und verhindert so ein Abgreifen über unverschlüsseltes HTTP. Keins von beiden verschlüsselt das Cookie im Ruhezustand; beide sind eine Einzeilen-Härtung im Set-Cookie-Header.
Ähnliche Tools
JWT-Parser
JSON Web Tokens (JWT) sofort decodieren und verifizieren. Header-, Payload- und Signaturinformationen mit lesbarem Zeitformat anzeigen
HTTP-Header-Parser
Rohe HTTP-Header in eine strukturierte Tabelle parsen mit Cookie-Extraktion
URL-Parser
URLs in ihre Bestandteile zerlegen — Schema, Host, Port, Pfad, Query-Parameter und Fragment
Autoritative Referenzen
Primärquellen hinter diesem Tool – offizielle Standards und Spezifikationen, keine zweihändigen Zusammenfassungen.
RFC 6265 - HTTP State Management Mechanism
Der IETF-Standard HTTP State Management Mechanism, der Cookies und ihre Attribute definiert.
MDN Web Docs - Set-Cookie
Mozilla-Referenz zum Set-Cookie-Header: Attribute, Präfixe und Sicherheits-Flags.
HTTP cookie - Wikipedia
Wie HTTP-Cookies Zustand übertragen: Sessions, Attribute und Same-Site-Regeln.