English
Deutsch
PolskiSecure, HttpOnly, SameSite: Schutz und Grenzen von Cookies
Management Summary
Cookie-Schutz richtet sich nach dem Zweck des gespeicherten Werts, besonders bei bestehenden Anmeldungen. Secure begrenzt die Übertragung auf geschützte Verbindungen, HttpOnly verhindert direkten Skriptzugriff und SameSite beschränkt das Mitsenden bei websiteübergreifenden Anfragen. Diese Maßnahmen ergänzen sich, ersetzen aber keine sichere Anwendung. Eine belastbare Prüfung untersucht tatsächliche Speicherung und Verhalten bei Anmeldung und Navigation. Das Zählen von Merkmalen oder ein einzelner Seitenabruf reicht dafür nicht.
Inhalt
Secure, HttpOnly und SameSite schützen unterschiedliche Teile des Cookie-Einsatzes. Die passende Kombination hängt vom Zweck ab: Ein Sitzungsnachweis, an dem der Server eine bestehende Anmeldung erkennt, braucht andere Eigenschaften als eine ungefährliche Anzeigeeinstellung, die JavaScript auslesen soll. Eine bloße Zählung gesetzter Attribute ergibt deshalb keine Sicherheitsrangliste.
Secure: Übertragung über HTTPS
Secure beschränkt das Mitsenden auf sichere Verbindungen, bei gewöhnlichen Websites also HTTPS. Für localhost bestehen Browserausnahmen. Das Attribut verschlüsselt den Cookie-Wert nicht zusätzlich und verhindert keinen JavaScript-Zugriff.
Ohne Secure kann ein passendes Cookie bei einer HTTP-Anfrage unverschlüsselt übertragen werden. Eine anschließende HTTPS-Weiterleitung kommt dafür zu spät. Bereits wirksames HSTS kann die HTTP-Verbindung vor dem Versand auf HTTPS umstellen; ein erstmals empfangener HSTS-Header schützt jedoch nicht rückwirkend die erste HTTP-Anfrage. HTTPS allein fügt Cookies auch nicht automatisch Secure hinzu.
HttpOnly: kein Zugriff über document.cookie
HttpOnly entzieht das Cookie den üblichen JavaScript-Cookie-APIs. Das erschwert den direkten Diebstahl eines Sitzungswerts durch eingeschleuste Skripte. Der Browser kann das Cookie trotzdem an passende Anfragen anhängen, auch wenn JavaScript die Anfrage auslöst. HttpOnly beseitigt deshalb keine XSS-Schwachstelle (Ausführung eingeschleuster Skripte) und verhindert nicht sämtliche Aktionen innerhalb einer kompromittierten Sitzung.
Für serverseitige Sitzungsnachweise ist HttpOnly regelmäßig sinnvoll. Eine bewusst per JavaScript gelesene Anzeigeeinstellung kann dieses Attribut dagegen nicht verwenden. JavaScript kann HttpOnly nicht über document.cookie setzen. Ein fehlendes Attribut muss deshalb nach Cookie-Zweck bewertet werden, nicht allein nach Häufigkeit.
SameSite: Kontext statt Verschlüsselung
„Same-site“ ist nicht dasselbe wie „same-origin“. Bei gewöhnlichen Domains zählt das Schema zusammen mit der registrierbaren Domain. https://shop.example.com und https://login.example.com sind beispielsweise same-site, aber verschiedene Origins. Ein Wechsel von HTTPS zu HTTP ist cross-site.
Strict: restriktiv für siteübergreifende Kontexte; auch ein externer Link kann zunächst ohne das Cookie ankommen.Lax: erlaubt zusätzlich bestimmte siteübergreifende Navigationen im obersten Browserfenster mit sicheren Methoden, etwa einen gewöhnlichen GET-Link. Ein eingebetteter Abruf oder ein gewöhnlicher Cross-site-POST fällt nicht darunter.None: hebt die SameSite-Beschränkung auf und erfordert Secure. Andere Cookie- und Datenschutzregeln gelten weiterhin; Drittanbieter-Cookies sind dadurch nicht garantiert verfügbar.
Einige Browser verwenden ohne explizite Angabe eine Lax-Voreinstellung. Diese kann zeitlich begrenzte Ausnahmen für kürzlich gesetzte Cookies bei POST enthalten. Fehlendes SameSite bedeutet daher weder „überall mitsenden“ noch vollständigen CSRF-Schutz (gegen unerwünscht ausgelöste Anfragen mit bestehender Anmeldung). Explizite SameSite-Werte machen die Versandregeln nachvollziehbarer. Anfragen, die Daten ändern, etwa eine Adressänderung, benötigen zusätzliche Schutzmaßnahmen wie geprüfte CSRF-Tokens.
Ein Beispiel für einen serverseitigen Sitzungsnachweis
Set-Cookie: __Host-session=SERVER_GENERATED_RANDOM_VALUE; Path=/; Secure; HttpOnly; SameSite=LaxDer Wert SERVER_GENERATED_RANDOM_VALUE ist ein Platzhalter für einen vom Server erzeugten sicheren Zufallswert. Das Präfix __Host- verlangt in unterstützenden Browsern Secure, Path=/ und das Fehlen eines Domain-Attributs. Das Cookie bleibt dadurch auf den setzenden Host begrenzt. Lax ist eine mögliche Ausgangskonfiguration; Anmeldeweiterleitungen und eingebettete Anwendungen brauchen einen eigenen Funktionstest.
Was eine Headerprüfung tatsächlich aussagt
Eine Set-Cookie-Zeile ist zunächst eine Anweisung, kein Beweis für ein gespeichertes Cookie. Ein Browser kann die Anweisung zurückweisen; eine Zeile kann auch ein Cookie ersetzen oder löschen. Mehrere Antworten einer Weiterleitungskette sind getrennt zu erfassen.
Ein einfacher Abruf der Startseite übersieht außerdem per JavaScript erzeugte Cookies sowie Antworten späterer Skript-, Bild- oder API-Anfragen. Kein Set-Cookie im Hauptdokument bedeutet deshalb nicht „die Website setzt keine Cookies“. Auch ein Aufruf ohne Klicks kann Skripte und weitere Abrufe auslösen.
Für eine belastbare Prüfung werden ein frisches Browserprofil, Browserversion, Start-URL, Zeitpunkt und Interaktionsfolge dokumentiert. Netzwerkantworten und tatsächlich gespeicherte Cookies werden getrennt verglichen. Zu jedem Cookie gehören Zweck, Host, Pfad, Lebensdauer und erforderlicher Skriptzugriff. Ein Attributzähler allein beantwortet keine dieser Fragen.
Fragen und Antworten
Ist HttpOnly wichtiger als Secure?
Eine allgemeine Rangfolge ist nicht sinnvoll. Ein Sitzungswert braucht sowohl Schutz beim Transport als auch Schutz vor direktem Skriptzugriff. SameSite ergänzt den Kontextschutz. Keines dieser Attribute ersetzt serverseitige Berechtigungsprüfungen oder die Behebung von XSS.
Kann Path den Zugriff verschiedener Anwendungen sicher trennen?
Path steuert die Auswahl für den Versand, ist aber keine verlässliche Sicherheitsgrenze gegen Skripte auf demselben Host. Für getrennte Vertrauensbereiche sind passende Host- und Anwendungsgrenzen erforderlich.
Beweist eine hohe Attributquote eine sichere Website?
Nein. Ein fehlendes HttpOnly kann bei einer harmlosen JavaScript-Einstellung beabsichtigt sein; ein vollständig markiertes Sitzungs-Cookie kann trotzdem zu einer fehlerhaft geschützten Anwendung gehören. Entscheidend sind Zweck, wirksames Browserverhalten und serverseitige Verarbeitung.
Passend dazu
