Set-Cookie-Header prüfen
Set-Cookie-Header prüfen und verstehen: Das Werkzeug zerlegt jede Zeile und bewertet Secure, HttpOnly, SameSite, Laufzeit und die Präfixe __Host- und __Secure-.
Alles läuft in Ihrem Browser. Eingaben verlassen Ihr Gerät nicht.
Cookie-Attribute richtig setzen
Mit diesem Werkzeug können Sie einen Set-Cookie-Header prüfen, wie ihn Ihr Server oder Ihr Framework ausliefert. Kopieren Sie die Zeilen aus den Entwicklerwerkzeugen des Browsers (Netzwerk, Antwort-Header) oder aus curl -I. Jede Zeile wird in Name, Wert und Cookie-Attribute zerlegt und nach den Regeln von RFC 6265 und dessen Überarbeitung bewertet, die die Browser heute umsetzen.
Die wichtigsten Attribute: Das Secure-Flag sorgt dafür, dass der Browser das Cookie nur über HTTPS sendet. HttpOnly versteckt es vor JavaScript, was gestohlene Sitzungen per XSS deutlich erschwert. SameSite steuert, ob das Cookie bei Anfragen von fremden Websites mitgeht: Strict nie, Lax nur bei normaler Navigation, None immer, dann aber nur zusammen mit Secure. Fehlt SameSite, behandeln Chromium-Browser das Cookie wie Lax; andere Browser verhalten sich teils anders, deshalb lohnt sich die ausdrückliche Angabe.
Präfixe im Namen machen Zusagen, die der Browser erzwingt: Ein Cookie mit __Secure- wird nur mit Secure angenommen. Das __Host-Präfix verlangt zusätzlich Path=/ und verbietet Domain, damit keine Subdomain das Cookie überschreiben kann. Für Sitzungscookies ist __Host-name=…; Path=/; Secure; HttpOnly; SameSite=Lax eine gute Grundlage. Die Prüfung ersetzt keinen Test im Browser, denn manche Grenzen wie die maximale Laufzeit unterscheiden sich je Browser. Weitere Antwort-Header bewertet der Sicherheits-Header-Prüfer.
Anleitung: Set-Cookie-Header prüfen in 4 Schritten
- Die Set-Cookie-Zeilen aus den Entwicklerwerkzeugen des Browsers (Netzwerk, Antwort-Header) oder aus
curl -Ikopieren. - Die Zeilen in das Feld einfügen, eine je Zeile, mit oder ohne „Set-Cookie:“.
- Die Bewertung von Secure, HttpOnly, SameSite, Laufzeit und Präfixen für jedes Cookie lesen.
- Die Konfiguration im Server oder Framework anpassen und die neuen Zeilen erneut prüfen.
Typische Anwendungsfälle
- Login absichern: Prüfen, ob das Sitzungscookie Secure, HttpOnly und SameSite trägt.
- Eingebettete Inhalte: Kontrollieren, ob ein Cookie für iframes oder fremde Websites mit SameSite=None und Secure gesetzt ist.
- Sicherheitsprüfung: Befunde aus einem Penetrationstest zu Cookie-Attributen nachvollziehen und nach der Korrektur bestätigen.
Häufige Fragen
Welche Cookie-Attribute braucht ein Sitzungscookie?
Secure, HttpOnly, SameSite=Lax oder Strict und Path=/, ohne Domain. Mit dem Präfix __Host- im Namen erzwingt der Browser diese Kombination. Eine Laufzeit über Max-Age ist nur nötig, wenn die Sitzung das Schließen des Browsers überdauern soll.
Was passiert bei SameSite=None ohne Secure?
Moderne Browser lehnen das Cookie ab. SameSite=None ist nur zusammen mit dem Secure-Flag erlaubt, also für Cookies, die ausschließlich über HTTPS gesendet werden.
Was gilt, wenn Expires und Max-Age gesetzt sind?
Max-Age hat Vorrang. Ein Wert von 0 oder kleiner löscht das Cookie sofort. Fehlen beide Attribute, ist es ein Sitzungscookie, das beim Schließen des Browsers endet; manche Browser stellen solche Cookies beim Wiederherstellen der Sitzung aber wieder her.
Warum ist Domain=.example.de oft keine gute Idee?
Mit Domain wird das Cookie an alle Subdomains gesendet und kann von dort auch überschrieben werden. Ohne Domain gilt es nur für den genauen Host, der es gesetzt hat. Der führende Punkt wird heute ignoriert.
Wie lange darf ein Cookie gültig sein?
Chromium-Browser begrenzen die Laufzeit auf 400 Tage, auch wenn Expires oder Max-Age mehr angeben. Safari kürzt Cookies, die per JavaScript gesetzt werden, unter bestimmten Bedingungen auf sieben Tage.
Wie sehe ich die Set-Cookie-Header einer Website?
In den Entwicklerwerkzeugen des Browsers (F12) im Bereich Netzwerk die Anfrage anklicken und die Antwort-Header ansehen. In der Kommandozeile zeigt curl -I https://example.de die Header der Antwort.
Warum wird mein Cookie im iframe nicht gesendet?
In einem iframe einer fremden Website gilt das Cookie als Drittanbieter-Cookie. Es wird nur mit SameSite=None und Secure mitgeschickt, und auch dann blockieren manche Browser wie Safari Drittanbieter-Cookies grundsätzlich.
Das könnte auch helfen
Hash-Generator
MD5, SHA-1, SHA-256, SHA-384 und SHA-512 für Text oder Datei berechnen und vergleichen.
ÖffnenHMAC-Generator
HMAC mit SHA-256, SHA-512, SHA-1 oder MD5 berechnen und Webhook-Signaturen prüfen.
ÖffnenPasswort-Generator
Sichere Zufallspasswörter mit wählbarer Länge und Zeichengruppen, inklusive Entropie in Bit.
ÖffnenPasswort-Stärke prüfen
Passwort testen: Entropie, typische Muster, häufige Passwörter und grobe Knackzeit.
ÖffnenPassphrase-Generator
Merkbare Passphrasen aus einer deutschen Wortliste mit über 2.000 Wörtern, nach Diceware-Art.
ÖffnenToken-Generator
Zufalls-Token als Hex, Base64URL oder alphanumerisch erzeugen, etwa für API-Keys und Secrets.
Öffnen