![\"Zw\u00f6lf](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/cookie-flags-de.png\")
Drei W\u00f6rter, drei verschiedene Gefahren<\/h2>\n
Drei T\u00fcren, und keine der drei hilft bei dem, was die anderen beiden bewachen.<\/p>\n Am 2. September 2026 wurden zwanzig gro\u00dfe Startseiten jeweils einmal ge\u00f6ffnet. Dabei wurden Weiterleitungen verfolgt, aber weder etwas angenommen noch angeklickt. Alle zwanzig antworteten mit Status 200.<\/p>\n Gez\u00e4hlt wurde jede Was ein Einwilligungsbanner danach hinzuf\u00fcgt, ist eine eigene Frage und eine weit gr\u00f6\u00dfere Zahl. Das hier ist der Boden, nicht die Decke.<\/p>\n Die gr\u00f6\u00dfte einzelne Gruppe der Messung setzt beim ersten Besuch \u00fcberhaupt kein Cookie: zw\u00f6lf der zwanzig.<\/p>\n Das sind \u00fcberwiegend Projekt- und Dokumentationsseiten – jene Art Seite, die Text zeigt und nichts zu merken hat. Das geh\u00f6rt deutlich gesagt, denn die Angaben werden erst zur Frage, nachdem die Entscheidung f\u00fcr ein Cookie gefallen ist, und diese Entscheidung f\u00e4llt h\u00e4ufiger weg, als eines der drei W\u00f6rter benutzt wird.<\/p>\n Die \u00fcbrigen acht Seiten setzen zusammen 29 Cookies, von einem einzigen bis zu zehn auf einer Seite.<\/p>\n Von diesen 29 Cookies trugen 23 das Wort Diese Reihenfolge ist kein Zufall. Wikipedia setzte die meisten und bewachte sie am besten: zehn Cookies, jedes einzelne Die New York Times setzte neun, und kein einziges davon war Und zwei Seiten setzten je ein Cookie, das keines der drei W\u00f6rter trug: apple.com und php.net. Je ein Cookie, keine Verschl\u00fcsselungspflicht, f\u00fcr jedes Skript lesbar, von \u00fcberall her mitgeschickt.<\/p>\n Die drei W\u00f6rter sind nicht gleich gut zu ersetzen.<\/p>\n Ohne Ohne Ohne Deshalb l\u00e4uft die hier gemessene Reihenfolge verkehrt herum. Das am seltensten gesetzte Wort ist jenes, f\u00fcr das nichts anderes einspringt.<\/p>\n Nein. HttpOnly hei\u00dft, dass kein Skript das Cookie lesen kann, und damit scheidet jedes Cookie aus, das f\u00fcr ein Skript da ist: der Einwilligungsstand, den ein Banner-Skript beim n\u00e4chsten Aufruf lesen muss, oder die Kennung, die ein Analysewerkzeug im Browser selbst schreibt und liest.<\/p>\n Ein Skript kann HttpOnly zudem gar nicht setzen. Wenn es Cookies \u00fcber F\u00fcr alles, was nur der Server braucht, gilt das Gegenteil: Sitzungs- und Anmelde-Cookies liest kein Skript, und f\u00fcr 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.<\/p>\n Nur teilweise. HttpOnly verhindert, dass ein Skript den Wert liest und mitnimmt, um die Sitzung sp\u00e4ter 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.<\/p>\n 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\u00fcrfen, und eine sparsame Auswahl fremder Skripte.<\/p>\n Weil Chrome und die \u00fcbrigen Chromium-basierten Browser ein Cookie mit SameSite=None ohne Secure seit 2020 gar nicht erst annehmen. Ein Cookie, das ausdr\u00fccklich auch f\u00fcr Anfragen von fremden Seiten freigegeben wird, muss also auf verschl\u00fcsselte Verbindungen beschr\u00e4nkt sein.<\/p>\n<\/div>\nSecure<\/code> hei\u00dft: Das Cookie reist nur \u00fcber eine verschl\u00fcsselte Verbindung. Ohne dieses Wort reicht eine einzige Anfrage \u00fcber einfaches HTTP – eine vertippte Adresse, ein altes Lesezeichen, ein Link in einer E-Mail – und der Wert liegt f\u00fcr jeden im selben Netz offen.<\/p>\nHttpOnly<\/code> hei\u00dft: Skripte im Browser k\u00f6nnen das Cookie nicht lesen. Das Wort gibt es f\u00fcr den Fall, dass auf einer Seite Code l\u00e4uft, den niemand dort haben wollte: ein eingeschleustes Skript, eine \u00fcbernommene fremde Bibliothek, eine schlechte Anzeige. Ohne dieses Wort liest solcher Code das Sitzungs-Cookie in einer einzigen Zeile.<\/p>\nSameSite<\/code> 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\u00fchrt, wer gerade angemeldet ist.<\/p>\nWas gemessen wurde<\/h2>\n
Set-Cookie<\/code>-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.<\/p>\nZw\u00f6lf von zwanzig setzen gar nichts<\/h2>\n
![\"Eine](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/illustrationen\/illu-cookie-flags.webp\")
\n<\/figure>\nSecure ist die Regel, HttpOnly die Ausnahme<\/h2>\n
Secure<\/code>, 17 das Wort SameSite<\/code> und 12 das Wort HttpOnly<\/code>.<\/p>\nSecure<\/code> l\u00e4uft inzwischen fast von allein mit: Browser dr\u00e4ngen seit Jahren darauf, und Bauk\u00e4sten setzen es auf einer verschl\u00fcsselten Seite voreingestellt. SameSite<\/code> kam mit einem Standardwert, ein Cookie ohne das Wort wird also behandelt, als h\u00e4tte es die mittlere Einstellung verlangt – das Wort fehlt oft, der Schutz nicht.<\/p>\nHttpOnly<\/code> hat keinen solchen Standardwert. Ein Cookie ohne dieses Wort ist f\u00fcr jedes Skript auf der Seite lesbar, und nichts tr\u00e4gt das Wort nach, wenn es niemand hinschreibt.<\/p>\nDrei F\u00e4lle im Einzelnen<\/h2>\n
Secure<\/code>, sechs davon HttpOnly<\/code>. Nur vier trugen SameSite<\/code>, was genau zum Muster oben passt.<\/p>\nHttpOnly<\/code>. F\u00fcnf waren Secure<\/code>, f\u00fcnf trugen SameSite<\/code> – die Schutzma\u00dfnahmen gegen ein Cookie auf falschem Weg waren also teilweise da, jene gegen ein lesendes Skript fehlte vollst\u00e4ndig.<\/p>\nWas ein fehlendes HttpOnly wirklich kostet<\/h2>\n
Secure<\/code> entweicht ein Cookie bei einer unverschl\u00fcsselten Anfrage – und auf einer Seite, die alles auf HTTPS umleitet und einen strengen Transport-Header schickt, kommt diese Anfrage weitgehend nicht vor.<\/p>\nSameSite<\/code> greift die Voreinstellung des Browsers, die den schlimmsten Fall von allein abwehrt.<\/p>\nHttpOnly<\/code> springt nichts ein. Das Cookie ist f\u00fcr jeden Code lesbar, der auf der Seite l\u00e4uft, und dass fremder Code auf einer Seite l\u00e4uft, ist kein seltenes Ereignis: Es ist die gew\u00f6hnliche Folge davon, dass irgendwo weit weg ein einziges eingebundenes Fremdskript \u00fcbernommen wurde.<\/p>\nFragen und Antworten<\/h2>\n
L\u00e4sst sich jedes Cookie mit HttpOnly setzen?<\/h3>\n
document.cookie<\/code> anlegt, geschieht das nicht per Header. Solche Cookies erscheinen daher in keiner Set-Cookie-Zeile und wurden im Artikel nicht mitgez\u00e4hlt; f\u00fcr sie stellt sich die Frage nach diesem Attribut nicht.<\/p>\nIst eine Seite mit HttpOnly-Sitzungs-Cookie vor einem eingeschleusten Skript sicher?<\/h3>\n
Warum tragen Cookies mit SameSite=None praktisch immer auch Secure?<\/h3>\n