English
DeutschSecure, HttpOnly, SameSite: Was zwanzig Startseiten ihren Cookies mitgeben
Inhalt
Ein Cookie ist eine kurze Zeile, die der Server einem Browser zum Merken und Zurückschicken gibt. Drei optionale Attribute lassen sich ergänzen; jedes richtet sich gegen ein anderes Sicherheitsrisiko.
Das Hinzufügen kostet nichts. An zwanzig großen Startseiten gemessen sind zwei der drei verbreitet, und das dritte fehlt häufiger, als es da ist – und genau das ist jenes, auf das es ankommt, wenn schon etwas schiefgegangen ist.
Drei Wörter, drei verschiedene Gefahren
Secure heißt: Das Cookie reist nur über eine verschlüsselte Verbindung. Ohne dieses Wort reicht eine einzige Anfrage über einfaches HTTP – eine vertippte Adresse, ein altes Lesezeichen, ein Link in einer E-Mail – und der Wert liegt für jeden im selben Netz offen.
HttpOnly heißt: Skripte im Browser können das Cookie nicht lesen. Das Wort gibt es für den Fall, dass auf einer Seite Code läuft, den niemand dort haben wollte: ein eingeschleustes Skript, eine übernommene fremde Bibliothek, eine schlechte Anzeige. Ohne dieses Wort liest solcher Code das Sitzungs-Cookie in einer einzigen Zeile.
SameSite regelt, ob das Cookie mitgeschickt wird, wenn die Anfrage von einer anderen Seite kommt. Es ist die Abwehr gegen ein verstecktes Formular auf einer fremden Seite, das eine Handlung im Namen dessen ausführt, wer gerade angemeldet ist.
Drei Türen, und keine der drei hilft bei dem, was die anderen beiden bewachen.
Was gemessen wurde
Am 2. September 2026 wurden zwanzig große Startseiten jeweils einmal geöffnet. Dabei wurden Weiterleitungen verfolgt, aber weder etwas angenommen noch angeklickt. Alle zwanzig antworteten mit Status 200.
Gezählt wurde jede Set-Cookie-Zeile genau so, wie sie ankam: die Cookies also, die vor jeder Einwilligung gesetzt werden – genau der Satz, den ein Besuch einsammelt, ohne irgendetwas zu tun.
Was ein Einwilligungsbanner danach hinzufügt, ist eine eigene Frage und eine weit größere Zahl. Das hier ist der Boden, nicht die Decke.
Zwölf von zwanzig setzen gar nichts
Die größte einzelne Gruppe der Messung setzt beim ersten Besuch überhaupt kein Cookie: zwölf der zwanzig.
Das sind überwiegend Projekt- und Dokumentationsseiten – jene Art Seite, die Text zeigt und nichts zu merken hat. Das gehört deutlich gesagt, denn die Angaben werden erst zur Frage, nachdem die Entscheidung für ein Cookie gefallen ist, und diese Entscheidung fällt häufiger weg, als eines der drei Wörter benutzt wird.
Die übrigen acht Seiten setzen zusammen 29 Cookies, von einem einzigen bis zu zehn auf einer Seite.
Secure ist die Regel, HttpOnly die Ausnahme
Von diesen 29 Cookies trugen 23 das Wort Secure, 17 das Wort SameSite und 12 das Wort HttpOnly.
Diese Reihenfolge ist kein Zufall. Secure läuft inzwischen fast von allein mit: Browser drängen seit Jahren darauf, und Baukästen setzen es auf einer verschlüsselten Seite voreingestellt. SameSite kam mit einem Standardwert, ein Cookie ohne das Wort wird also behandelt, als hätte es die mittlere Einstellung verlangt – das Wort fehlt oft, der Schutz nicht.
HttpOnly hat keinen solchen Standardwert. Ein Cookie ohne dieses Wort ist für jedes Skript auf der Seite lesbar, und nichts trägt das Wort nach, wenn es niemand hinschreibt.
Drei Fälle im Einzelnen
Wikipedia setzte die meisten und bewachte sie am besten: zehn Cookies, jedes einzelne Secure, sechs davon HttpOnly. Nur vier trugen SameSite, was genau zum Muster oben passt.
Die New York Times setzte neun, und kein einziges davon war HttpOnly. Fünf waren Secure, fünf trugen SameSite – die Schutzmaßnahmen gegen ein Cookie auf falschem Weg waren also teilweise da, jene gegen ein lesendes Skript fehlte vollständig.
Und zwei Seiten setzten je ein Cookie, das keines der drei Wörter trug: apple.com und php.net. Je ein Cookie, keine Verschlüsselungspflicht, für jedes Skript lesbar, von überall her mitgeschickt.
Was ein fehlendes HttpOnly wirklich kostet
Die drei Wörter sind nicht gleich gut zu ersetzen.
Ohne Secure entweicht ein Cookie bei einer unverschlüsselten Anfrage – und auf einer Seite, die alles auf HTTPS umleitet und einen strengen Transport-Header schickt, kommt diese Anfrage weitgehend nicht vor.
Ohne SameSite greift die Voreinstellung des Browsers, die den schlimmsten Fall von allein abwehrt.
Ohne HttpOnly springt nichts ein. Das Cookie ist für jeden Code lesbar, der auf der Seite läuft, und dass fremder Code auf einer Seite läuft, ist kein seltenes Ereignis: Es ist die gewöhnliche Folge davon, dass irgendwo weit weg ein einziges eingebundenes Fremdskript übernommen wurde.
Deshalb läuft die hier gemessene Reihenfolge verkehrt herum. Das am seltensten gesetzte Wort ist jenes, für das nichts anderes einspringt.
Fragen und Antworten
Lässt sich jedes Cookie mit HttpOnly setzen?
Nein. HttpOnly heißt, dass kein Skript das Cookie lesen kann, und damit scheidet jedes Cookie aus, das für ein Skript da ist: der Einwilligungsstand, den ein Banner-Skript beim nächsten Aufruf lesen muss, oder die Kennung, die ein Analysewerkzeug im Browser selbst schreibt und liest.
Ein Skript kann HttpOnly zudem gar nicht setzen. Wenn es Cookies über document.cookie anlegt, geschieht das nicht per Header. Solche Cookies erscheinen daher in keiner Set-Cookie-Zeile und wurden im Artikel nicht mitgezählt; für sie stellt sich die Frage nach diesem Attribut nicht.
Für alles, was nur der Server braucht, gilt das Gegenteil: Sitzungs- und Anmelde-Cookies liest kein Skript, und für sie gibt es keinen Grund, auf HttpOnly zu verzichten. Eine brauchbare Faustregel lautet deshalb: Was der Server setzt und kein Skript der Seite liest, bekommt HttpOnly.
Ist eine Seite mit HttpOnly-Sitzungs-Cookie vor einem eingeschleusten Skript sicher?
Nur teilweise. HttpOnly verhindert, dass ein Skript den Wert liest und mitnimmt, um die Sitzung später anderswo zu benutzen. Es verhindert nicht, dass das Skript innerhalb der Seite handelt: Anfragen, die es von dort aus schickt, versieht der Browser automatisch mit dem Cookie, und damit kann es alles tun, was die angemeldete Person gerade tun darf, solange die Seite offen ist.
HttpOnly begrenzt also den Schaden, statt ihn zu verhindern. Gegen das eingeschleuste Skript selbst helfen andere Mittel, etwa eine Content-Security-Policy, die festlegt, woher Skripte kommen dürfen, und eine sparsame Auswahl fremder Skripte.
Warum tragen Cookies mit SameSite=None praktisch immer auch Secure?
Weil Chrome und die übrigen Chromium-basierten Browser ein Cookie mit SameSite=None ohne Secure seit 2020 gar nicht erst annehmen. Ein Cookie, das ausdrücklich auch für Anfragen von fremden Seiten freigegeben wird, muss also auf verschlüsselte Verbindungen beschränkt sein.
Quellen
Passend dazu
