Session-Cookies absichern: Secure, HttpOnly, SameSite

Ein Ampelposten, der drei verschiedene Angriffe abdeckt

In Berichten über Sicherheits-Header steht das Cookie meistens am Rand. Der Beitrag zu den Antwort-Headern und ihrer Wirkung behandelt HSTS, Content-Security-Policy, X-Frame-Options und Referrer-Policy - also das, was der Server über die Antwort selbst aussagt. Die Cookie-Attribute stehen in derselben Antwort, gehören aber zu einer anderen Klasse: Sie beschreiben nicht das Dokument, sondern den Ausweis, den der Browser danach bei jeder weiteren Anfrage mitschickt.

In einem Sicherheitsscan verschwindet dieser Unterschied. Dort steht eine Zeile - Cookies mit Secure-Attribut, erfüllt oder nicht erfüllt - mit einem einstelligen Punktabzug im Gesamtwert. Diese eine Zeile fasst drei voneinander unabhängige Fragen zusammen: ob die Kennung über eine unverschlüsselte Verbindung nach draußen gelangen kann, ob ein eingeschleustes Skript sie auslesen kann und ob ein fremder Absender den Browser dazu bringen kann, sie mitzuschicken. Drei Attribute, drei Angriffswege, ein Punkt.

Wer den Punktabzug ernst nimmt, sollte wissen, welche der drei Fragen offen ist. Der Sicherheitsscan von XICTRAQ liest jedes gesetzte Cookie einzeln aus und hält Name, Secure, HttpOnly und den SameSite-Wert getrennt fest - genau dafür, damit aus dem Ampelpunkt wieder eine Diagnose wird.

Secure: das Attribut gegen die Klartextzeile

RFC 6265 beschreibt Secure knapp: Das Attribut begrenzt den Geltungsbereich des Cookies auf gesicherte Kanäle, und der Browser hängt es nur an eine Anfrage an, die über einen gesicherten Kanal läuft - typischerweise HTTP über TLS (RFC 6265). Fehlt das Attribut, führt der Schwachstellenkatalog MITRE das als eigene Klasse: Das Secure-Attribut für schützenswerte Cookies in HTTPS-Sitzungen ist nicht gesetzt, CWE-614 (MITRE CWE).

Der häufigste Einwand lautet, die Seite laufe ohnehin vollständig über HTTPS. Das OWASP-Merkblatt zur Sitzungsverwaltung widerspricht dem ausdrücklich: Eine Anwendung auf HTTPS zu zwingen schützt die Sitzungskennung nicht, solange das Secure-Attribut fehlt - der Browser lässt sich dazu bringen, die Kennung über eine unverschlüsselte Verbindung preiszugeben (OWASP). Ein Angreifer im selben Netz schleust dazu einen Verweis auf http:// ein und liest die Kennung aus der Anfrage mit. Mit der angekündigten HTTPS-Warnung in Chrome ab Oktober 2026 wird dieser Umweg sichtbarer, verschwindet aber nicht.

Gesetzt wird das Attribut trotzdem selten: 24 Prozent der Erstanbieter-Cookies tragen es (HTTP Archive Web Almanac). Bei Drittanbieter-Cookies liegt der Wert nahe bei hundert Prozent, allerdings nicht aus Sorgfalt - wer SameSite=None setzen will, muss Secure mitliefern, sonst verwirft der Browser das Cookie (HTTP Archive Web Almanac).

HttpOnly: die Grenze zwischen Skript und Sitzung

HttpOnly begrenzt den Geltungsbereich des Cookies auf HTTP-Anfragen. Der Browser lässt es weg, wenn der Zugriff über eine Schnittstelle erfolgt, die keine HTTP-Anfrage ist - also insbesondere über die Schnittstelle, die Cookies an Skripte weiterreicht (RFC 6265). Praktisch heißt das: document.cookie sieht das Cookie nicht, ein eingeschleustes Skript kann die Sitzungskennung nicht auslesen und nicht an einen fremden Empfänger schicken. Der Schwachstellenkatalog führt das Fehlen als CWE-1004: Das Produkt speichert schützenswerte Information in einem Cookie, das nicht mit dem HttpOnly-Kennzeichen versehen ist (MITRE CWE).

Die Grenze hat einen klar benannten Rand. OWASP hält fest, dass HttpOnly allein die Vertraulichkeit des Cookies schützt: Ein Angreifer kann es außerhalb des Skriptkontextes nicht verwenden - aber die Anfragen, die ein eingeschleustes Skript im Browser des Opfers auslöst, tragen das Cookie weiterhin, weil der Browser die Cookies beim Senden von Anfragen mitschickt (OWASP). HttpOnly verhindert das Abfließen der Kennung, nicht ihre Verwendung im laufenden Browser. Deshalb bleibt eine strenge Content-Security-Policy daneben sinnvoll: Sie setzt eine Stufe früher an.

Verbreitet ist das Attribut noch seltener als Secure: 12 Prozent der Erstanbieter- und etwas mehr als 26 Prozent der Drittanbieter-Cookies tragen es (HTTP Archive Web Almanac). Dass Drittanbieter hier vorn liegen, sagt wenig über Sorgfalt aus - deren Cookies werden schlicht seltener von eigenem Seitenskript gelesen. Für die eigene Sitzungskennung ist HttpOnly nach der Einordnung von OWASP verbindlich (OWASP).

SameSite: was der Browser bei fremden Absendern tut

SameSite ist das jüngste der drei Attribute und das einzige, das nicht regelt, wer das Cookie lesen darf, sondern wann der Browser es überhaupt anhängt. Die Entwurfsfassung des Cookie-Standards beschreibt drei Werte (RFC 6265bis):

• Strict - das Cookie wird nur bei Anfragen mitgeschickt, die von derselben Site ausgehen (RFC 6265bis). Ein Verweis aus einer fremden Domain führt in eine abgemeldete Ansicht.
• Lax - das Cookie wird bei Anfragen derselben Site mitgeschickt und darüber hinaus bei Navigationen der obersten Ebene, die von einer fremden Site kommen (RFC 6265bis). Der Verweis aus einer Suchmaschine landet in einer angemeldeten Ansicht, ein eingebettetes Formular einer fremden Domain bekommt das Cookie nicht.
• None - das Cookie wird bei Anfragen derselben und fremder Sites mitgeschickt (RFC 6265bis). Dieser Wert setzt Secure voraus; ohne verschlüsselte Verbindung verwirft der Browser das Cookie.
• Steht ein anderer Wert in der Zeile, behandelt der Browser ihn wie Lax (RFC 6265bis). Ein Tippfehler im Attribut fällt deshalb nicht als Fehler auf, sondern still als Wechsel der Regel.

Der Fall ohne Angabe verhält sich in verbreiteten Browsern ebenfalls wie Lax, aber in einer nachgiebigeren Variante: Cookies werden dabei auch bei POST-Anfragen mitgeschickt, solange sie nicht mehr als zwei Minuten vor der Anfrage gesetzt wurden (MDN). Wer sich auf den Vorgabewert verlässt, verlässt sich damit auf eine Variante, die je nach Browser und Version abweicht. OWASP rät dazu, den Wert für Sitzungscookies ausdrücklich zu setzen und sich nicht auf die Vorgabe des Browsers zu verlassen (OWASP).

Die Verbreitung ist entsprechend schief. Im Desktop-Lauf tragen 3 Prozent der Erstanbieter-Cookies SameSite=Strict, 19 Prozent Lax, 11 Prozent None und 66 Prozent gar keinen Wert (HTTP Archive Web Almanac). Bei Drittanbieter-Cookies liegt None bei nahezu hundert Prozent, weil sie sonst im fremden Kontext nicht mitgeschickt würden (HTTP Archive Web Almanac). Der Schwachstellenkatalog führt das fehlende oder unsicher gesetzte Attribut als CWE-1275 und nennt als Folge Cross-Site-Request-Forgery, wenn keine weitere Absicherung greift (MITRE CWE). Wer schon einmal einen Fehler in der Freigabe fremder Herkünfte gesucht hat, kennt die Nachbarschaft der Fragestellung.

Die Tabelle macht die Arbeitsteilung sichtbar: Kein Attribut ersetzt ein anderes. OWASP formuliert das für SameSite besonders deutlich - es ist eine Verteidigung in der Tiefe gegen Cross-Site-Request-Forgery und kein Ersatz für ein Token (OWASP). Und weil Browser die Vorgabewerte im Lauf der Jahre mehrfach verschoben haben, gehört der Zustand in eine Prüfung, die mit jedem Release mitläuft - der kürzere Takt der Chrome-Auslieferung ab 2026 verkürzt das Fenster dafür weiter.

Der Nachfolger des Standards steht noch im Entwurf

Ein Detail, das in Prüfberichten selten auftaucht: SameSite ist in keinem veröffentlichten RFC beschrieben. RFC 6265 stammt vom April 2011 und definiert von den drei Attributen nur Secure und HttpOnly (RFC 6265). Alles Weitere - SameSite, die Namenspräfixe, das Verhalten bei unbekannten Werten - steht in draft-ietf-httpbis-rfc6265bis, zuletzt in der Fassung 22 vom 1. Dezember 2025 (IETF). Das Dokument liegt in der Warteschlange des RFC-Editors und soll RFC 6265 ablösen, sobald es angenommen wird (IETF).

Für die Praxis folgt daraus zweierlei. Erstens ist der belastbare Bezugspunkt das Verhalten der ausgelieferten Browser und nicht ein abgeschlossenes Dokument: Änderungen an Vorgabewerten kommen über Browser-Releases, nicht über eine neue Fassung des Standards. Zweitens gehört die Formulierung im eigenen Sicherheitskonzept dazu. Wer SameSite als Anforderung schreibt, verweist sauber auf die Entwurfsfassung und nicht auf RFC 6265, in dem das Attribut nicht vorkommt.

Namenspräfixe binden das Cookie an seine Eigenschaften

Ein gesetztes Attribut sagt nichts darüber aus, ob es gesetzt bleibt. Eine Subdomain kann ein gleichnamiges Cookie überschreiben, und ein Angreifer mit Zugriff auf einen ungesicherten Kanal kann ein Secure-Cookie zwar nicht lesen, aber überschreiben - RFC 6265 nennt diese Einschränkung im Abschnitt zu Secure selbst und hält fest, dass das Attribut die Vertraulichkeit schützt und nicht die Unversehrtheit (RFC 6265). Die Namenspräfixe schließen genau diese Lücke, indem der Browser die Eigenschaften am Namen erzwingt.

Set-Cookie: __Host-SessionID=<wert>; Secure; HttpOnly; SameSite=Strict; Path=/

__Host-    erzwingt Secure, Path=/ und das Fehlen eines Domain-Attributs
__Secure-  erzwingt Secure

Beginnt der Name mit __Secure-, akzeptiert ein regelkonformer Browser das Cookie nur, wenn es das Secure-Attribut trägt. Beginnt er mit __Host-, müssen zusätzlich Path=/ gesetzt und das Domain-Attribut weggelassen sein - das Cookie ist damit an genau einen Host gebunden und wandert nicht über Subdomains (RFC 6265bis). OWASP empfiehlt __Host- ausdrücklich für Sitzungskennungen (OWASP). Wie die ausgelieferte Antwort im Ganzen aussieht, zeigt das Header-Werkzeug für einzelne Adressen.

Wo die Attribute im Betrieb verloren gehen

Cookie-Attribute sind kein Zustand, den man einmal herstellt. Sie entstehen an verschiedenen Stellen der Auslieferung, und jede dieser Stellen kann sie wieder entfernen, ohne dass dabei ein Fehler entsteht. Sechs Muster tauchen dabei besonders oft auf.

• Vorgaben des Anwendungsrahmens: Viele Rahmenwerke setzen Secure nur, wenn sie die Anfrage selbst als gesichert erkennen. Hinter einem Umkehrproxy, der TLS beendet, sehen sie eine Klartextanfrage und lassen das Attribut weg.
• Umschreibende Zwischenschichten: Ein Proxy oder eine Auslieferungsschicht darf Set-Cookie verändern. Was die Anwendung sendet, ist nicht zwingend das, was im Browser ankommt.
• Anmeldung über eine ungesicherte Antwort: Wird die Sitzung schon in der Antwort auf die Anfrage über http gesetzt und erst danach umgeleitet, ist die Kennung bereits einmal im Klartext gelaufen.
• Zweitanwendungen auf Subdomains: Ein Hilfeportal, ein Buchungsmodul oder eine Vorschauumgebung setzt eigene Cookies mit eigenen Vorgaben. Ohne __Host- teilen sie sich den Namensraum mit der Hauptanwendung.
• Abweichende Umgebungen: Die Abnahmeumgebung läuft ohne Zertifikat, das Attribut wird dort abgeschaltet, und die Abschaltung wandert mit der Konfiguration in die Auslieferung.
• Wechsel eines Vorgabewerts: Ändert ein Browser sein Verhalten bei fehlendem SameSite, ändert sich das Verhalten der eigenen Anwendung, ohne dass jemand etwas ausgeliefert hat.

Allen sechs Fällen ist gemeinsam, dass sie in der Anwendung selbst nicht auffallen. Der Anmeldevorgang funktioniert weiter, die Seite lädt, kein Protokoll meldet etwas. Sichtbar werden sie erst, wenn jemand die ausgelieferte Antwort ansieht - so, wie eine Prüfung des Anmeldewegs und des Bestellabschlusses den Weg selbst betrachtet und nicht nur die Startseite.

Einwilligung ist eine andere Frage

Sicherheitsattribute und Einwilligung werden regelmäßig vermischt, obwohl sie verschiedene Fragen beantworten. Nach Paragraf 25 Absatz 1 TDDDG ist die Speicherung von Informationen in der Endeinrichtung des Endnutzers nur mit dessen Einwilligung zulässig (TDDDG). Absatz 2 Nummer 2 nimmt davon aus, was unbedingt erforderlich ist, damit der Anbieter eines digitalen Dienstes einen vom Nutzer ausdrücklich gewünschten digitalen Dienst zur Verfügung stellen kann (TDDDG). Ein Cookie, das die Anmeldung trägt, fällt in der Regel darunter. Was der Entwurf zur Cookie-Banner-Reform 2026 daran ändern will, betrifft die Einholung der Einwilligung und nicht die Absicherung der Sitzung.

Die Attribute selbst sind keine Rechtsgrundlage und ersetzen keine. Sie senken das Risiko, dass eine ohnehin zulässige Kennung in fremde Hände gerät. Umgekehrt macht eine erteilte Einwilligung ein Cookie ohne Secure nicht sicherer. Wer beide Ebenen sauber trennt, kommt bei der Umsetzung der Einwilligung zu einer kürzeren Liste einwilligungspflichtiger Cookies und zu einer klareren Begründung für den Rest.

Cookie-Attribute laufend prüfen

Der Zustand lässt sich ohne großen Aufwand messen: Jede Antwort, die eine Sitzung eröffnet, trägt die Attribute in der Zeile Set-Cookie. Der Sicherheitsscan liest sie je Cookie einzeln aus - Name, Secure, HttpOnly und der SameSite-Wert stehen getrennt im Ergebnis, statt in einem einzelnen Ampelpunkt zusammenzufallen. Sieben Schritte machen daraus eine belastbare Routine.

1. Alle Sitzungscookies auflisten: Nicht nur das der Hauptanwendung. Zweitanwendungen, Vorschauumgebungen und Subdomains setzen eigene Kennungen mit eigenen Vorgaben.
2. Je Cookie die drei Attribute festhalten: Secure, HttpOnly und der SameSite-Wert gehören einzeln in die Liste, nicht als gemeinsames Urteil.
3. Den Wert für SameSite bewusst wählen: Strict für Kennungen, die Rechte tragen, Lax dort, wo ein Verweis von außen in einer angemeldeten Ansicht landen soll. None ist eine Entscheidung mit Begründung und kein Vorgabewert.
4. Ein Token gegen Cross-Site-Request-Forgery beibehalten: SameSite wirkt daneben und nicht anstelle (OWASP).
5. Namenspräfixe einführen, wo es ohne Umbau geht: __Host- für Sitzungskennungen, __Secure- dort, wo Subdomains das Cookie brauchen (RFC 6265bis).
6. Die Auslieferungskette einbeziehen: Gemessen wird die Antwort, die im Browser ankommt, nicht die, die die Anwendung erzeugt.
7. Änderungen melden lassen: Ein verschwundenes Attribut ist ein Ereignis und kein Zustand - es gehört gemeldet, wenn es verschwindet, und nicht erst im nächsten Bericht.

Der letzte Punkt macht in der Praxis den Unterschied. Ein monatlicher Bericht findet ein fehlendes HttpOnly bis zu vier Wochen nach der Änderung. Eine Benachrichtigung über den gewünschten Kanal findet es am Tag der Auslieferung.

Für einen ersten Blick ohne Konto genügt der Cookie-Scan für eine einzelne Adresse. Er zeigt, welche Cookies vor einer Einwilligung gesetzt werden und welche Attribute daran hängen - und damit auch, welche der drei Fragen aus diesem Beitrag bei Ihnen offen ist. Wer wissen möchte, welche Seiten überhaupt in der Messung stecken, findet den Weg dorthin im Beitrag zur Abdeckung des eigenen Seitenbestands.