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.

Mehrere Formate Sicherheits-Flags Cookie-Statistiken

Verwendung des Cookie-Parsers

1

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

2

Daten einfügen

Fügen Sie Ihre Set-Cookie-Header (einen pro Zeile) oder eine document.cookie-Zeichenkette in das Eingabefeld ein

3

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

Welche Cookie-Formate werden unterstützt?

Das Tool analysiert Set-Cookie-HTTP-Header und document.cookie-JavaScript-Zeichenketten. Mehrere Cookies können gleichzeitig analysiert werden.

Werden Sicherheits-Flags angezeigt?

Ja. HttpOnly, Secure, SameSite (Strict/Lax/None), Path und Domain-Attribute werden für jedes Cookie angezeigt.

Kann ich mehrere Cookies gleichzeitig analysieren?

Ja. Im Set-Cookie-Modus fügen Sie einen Header pro Zeile ein. Im document.cookie-Modus werden alle Cookies in der Zeichenkette analysiert.

Was bedeuten die Werte des SameSite-Attributs?

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.

Was ist der Unterschied zwischen Session-Cookies und persistenten Cookies?

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.

Was bewirken die Cookie-Präfixe __Secure- und __Host-?

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.

Wie groß dürfen Cookies sein und wie viele passen pro Domain?

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.

Wie schützen HttpOnly und Secure ein Cookie?

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.

{-- * External Resources Component(#18 Phase 3b 内容佐证工程) * 工具页「权威引用」区块:RFC / W3C / WHATWG / ECMA / IANA / 官方规范站 / Wikipedia。 * * - 接受 :slug 属性 → 经 config/tool-sources.php 家族矩阵渲染该工具的权威引用 * - slug 未命中映射时不渲染(无权威来源的工具静默跳过) * - 链接 title 保持英文(引用源专名);description 经 * common.resources.descriptions.{key} 本地化,lang 未命中回退英文(线上不裸奔) * - 链接保持 dofollow(rel="noopener noreferrer") * * @param string|null $slug --}}