• Was sind Cookies?
• Warum werden Cookies benötigt?
• Arten von Cookies
• Was man mit Cookies nicht machen sollte
• Cookies und Recht
• Risiken beim Cookie-Einsatz
• Cookies einsehen
• Aufbau von Cookies
• Wie werden Cookies gesetzt?
• Wie arbeiten Cookies?
• Cookie-Attribute erklärt
• Was man sonst noch über Cookies wissen sollte

Was sind Cookies?

In meinem Artikel “Wie Webseiten geladen werden” bin ich auf das HTTP-Protokoll kurz eingegangen. Dort beschrieb ich unter anderem:

Was ist also ein Cookie? Ein Cookie speichert Informationen über Nutzer in eine separate Textdatei. In der Regel werden diese Dateien in einem Ordner des Browsers gespeichert (client-seitig).

Warum werden Cookies benötigt?

Cookies können aus unterschiedlichen Gründen notwendig sein:

• Funktionsweise bzw. UX von Webseiten sicherstellen: Loggt man sich auf einer Webseite ein und verlässt diese, stellen Cookies beim nächsten Besuch sicher, dass man weiter eingeloggt bleibt. Oder im E-Commerce: Innerhalb einer Sitzung sorgen Cookies dafür, dass in den Warenkorb abgelegte Produkte erhalten bleiben, solange man auf der Webseite surft.
• Tracking: Google Analytics und andere Webanalyse-Dienste benutzen ebenfalls Cookies, um das Nutzerverhalten zu analysieren. Kommt ein Nutzer erstmalig auf die Website, dann bekommt dieser einen eindeutigen Wert innerhalb des Cookies. Kommt der Nutzer Tage später wieder auf die Website, lesen Tracking-Systeme den eindeutigen Wert aus und können so die Daten dem gleichen Nutzer zuordnen.
• Werbung: Im Werbebereich werden Cookies eingesetzt, um den Nutzer über mehrere Webseiten hinweg zu “verfolgen” und dadurch personalisierte Werbung (z.B. Banner) auszuspielen.

Arten von Cookies

Cookies können zunächst nach ihrer Zeitdauer (Session- und Permanent-Cookies) unterschieden werden:

• Session-Cookies: Ein Session-Cookie lebt nicht lange. Wenn eine Session im Browser beendet wird, dann wird das Session-Cookie gelöscht. Eine Session kann z.B. durch Schließen des Browsers beendet werden. Auch nach längerer Untätigkeit kann das Cookie zurückgesetzt bzw. gelöscht werden. Würde man für die Login-Funktionalität auf der Website ein Session-Cookie nutzen, dann würde das bedeuten, dass der Login-Zustand nur während der Session gespeichert wird. Schließt der Nutzer den Browser und kommt Stunden später wieder auf die Website, muss sich dieser nochmal einloggen.
• Permanent-Cookies: Möchte man jedoch Informationen über einen längeren Zeitraum speichern, machen permanente Cookies Sinn (auch Persistent Cookies genannt). Diese werden nach Beendigung der Session nicht gelöscht. Beim Anlegen des Cookies gibt man technisch dabei vor, wie lange der Cookie seine Gültigkeit haben soll. Beim Login auf Websites sieht man unter den Eingabefeldern immer wieder ein Kontrollkästchen mit “Merken” oder “Remember”, was man anklicken kann. Hier sind dann Permanent-Cookies im Spiel. Sobald der Haken gesetzt ist, wird beim Login ein Permanent-Cookie gesetzt, damit man auch nach Schließen der Session wiedererkannt wird. Somit muss man sich nicht nochmal einloggen. Zu beachten ist, dass Permanent-Cookie in bestimmten Fällen nicht ihre definierte Gültigkeit “ausleben” können. Das geschieht, wenn der Nutzer seine Browserdaten löscht. Oder wenn ein Nutzer im Inkognito-Modus surft, wo nach Schließen des Browser-Fenster automatisch alle Cookies gelöscht werden.

Auch nach der zugeordneten Domain können Cookies unterschieden werden: First- und Third-Party-Cookie.

• First-Party-Cookies: Hierbei handelt es sich um Cookies, die durch die Webseite gesetzt werden, auf die der Nutzer gerade surft. Der Nutzer kann hier nur von der Webseite erkannt werden, von der aus der Cookie gesetzt worden ist. Die oben 2 genannten Cookie-Arten “Funktionsweise bzw. UX von Webseiten sicherstellen” und “Tracking” sind z.B. First-Party-Cookies. Google Analytics setzt First-Party-Cookies ein. Standardmäßig blockieren Browser keine First-Party-Cookies. Nutzer können jedoch diese Cookies selbstständig löschen.
• Third-Party-Cookies: Hierbei handelt es sich um Cookies, die nicht durch die Webseite gesetzt werden, auf die der Nutzer gerade surft. Diese kommen bei Werbenetzwerken meist zum Einsatz. Besucht der Nutzer eine Webseite mit Werbung werden im Hintergrund Ressourcen (HTTP-Anfragen) des Ad-Servers geladen und dabei ein Cookie gesetzt. Besucht der Nutzer eine andere Webseite, wo der selbe Werbetreibende Werbung schaltet und Cookies setzt, kann dieser den Nutzer wiedererkennen (obwohl der Nutzer die Domain des Ad-Servers nie besucht hat). Durch das Verfolgen des Nutzers über mehrere Domains hinweg, kann ein Interessensprofil des Nutzers erstellt werden. Auf dieser Basis kann dann wiederum gezielt Werbung ausgespielt und für Retargeting und Remarketing genutzt werden. Diese Technik nennt sich auch Cross-Site-Tracking. Das Google Ads Conversion Tracking, Criteo und Doubleclick setzen bspw. Third-Party-Cookies ein.

Was man mit Cookies nicht machen sollte

Cookies können grundsätzlich für unterschiedliche Zwecke eingesetzt werden. Primär waren sie dazu gedacht trotz des zustandslosen HTTP-Protokolls den Nutzer wiederzuerkennen (z.B. Login-Status merken). Es gibt aber auch Fälle, wo Cookies für ganz andere Zwecke benutzt werden. Was nicht sinnvoll ist:

• Große Datenmengen sollten nicht in Cookies gespeichert werden. Per se sind sie mit 4 KB an Speichergröße begrenzt.
• Website-Einstellungen seitens der Nutzer sollten nicht in Cookies gespeichert werden (z.B. personalisierte Einstellungen in einem Login-Bereich). Löscht der Nutzer seine Cookies, gehen auch alle Einstellungen verloren, die der Nutzer für die Website gesetzt hat. Hier lieber eine Datenbank verwenden.

Cookies und Recht

In Deutschland galt lange Zeit das Telemediengesetz (TMG) von 2007. Dabei genügte ein Opt-Out bei der Nutzung von Cookies. § 15 Absatz 3 des Telemediengesetzes besagt:

Dies führte zu den kleinen Cookie-Bannern, meist am unteren Ende des Bildschirms. Nutzer konnten diesen mit Klick auf “OK” schließen. Der Nutzer hatte an dieser Stelle keine Wahlmöglichkeit, ob Cookies gesetzt werden sollten oder nicht. Man musste selbst aktiv im Nachhinein widersprechen (meist auf – für den Nutzer – umständlichen Weg). 2009 kam die ePrivacy-Richtlinie der EU. Artikel 5 Absatz 3 besagt, dass eine explizite Einwilligung bei Cookies erforderlich ist. Umgesetzt wurde dies in Deutschland lange Zeit nicht. Nach einer Übergangsphase trat dann am 25. Mai 2018 Datenschutzgrundverordnung (DSGVO) in Kraft. Dabei mussten die Websites ausführlich über den Cookie-Einsatz informieren und beim Erstaufruf der Website dem Nutzer die Möglichkeit geben, dem Einsatz von Cookies zu widersprechen. Ausgenommen von der Opt-Out-Pflicht waren notwendige Cookies, die wichtig waren, damit eine Website funktionieren kann.

Hier kamen dann Cookie-Banner zum Einsatz, die über die verschiedenen Cookie-Kategorien informierten. Die Checkboxen waren dabei voraktiviert. Der Nutzer musste sie also aktiv wegklicken, um zu widersprechen. Viele Nutzer klickten die Cookie-Banner sofort weg, um auf die Website-Inhalte zu gelangen. Daher entschied man im Oktober-Urteil von 2019, dass die Häkchen nicht vorausgewählt werden dürfen. Somit galt ab diesem Zeitpunkt eine Opt-In-Pflicht (mit Ausnahme von notwendigen Cookies).

Zusammenfassend kann man beim Einsatz von Cookies folgendes festhalten:

• Ein Opt-In ist unbedingt notwendig. Cookies zu Tracking- oder Marketing-Zwecken dürfen ohne Einwilligung nicht gesetzt werden.
• Eindeutig notwendige Cookies unterliegen nicht der Opt-In-Pflicht. Dazu zählen Cookies, um sich den Login-Status zu merken oder Cookies, die den Warenkorb speichern.
• Es gilt ein Kopplungsverbot. Der Opt-In darf keine Voraussetzung sein die Website besuchen zu können. Heißt: Wenn der Nutzer nicht zustimmt, darf die Website trotzdem besucht werden.
• Es ist eine aktive Zustimmung erforderlich. Hinweise wie “…wenn Sie unsere Website nutzen, dann stimmen Sie der Cookie-Nutzung zu…” sind nicht erlaubt. Der Nutzer muss aktiv die Checkbox aktivieren, damit die Cookies gesetzt werden dürfen.
• Es muss eine einfache Ablehnung möglich sein. Buttons wie “Ablehnen” oder “Nur notwendige Cookies erlauben” müssen gegeben sein.
• Als Webmaster muss man hinweisen, dass ein Opt-Out jederzeit möglich ist (im Consent Banner und in der Datenschutzerklärung).
• Links zum Impressum und zur Datenschutzerklärung müssen auf jeder Seite vorhanden sein.
• Es müssen genug Informationen zu Cookies vorhanden sein. Dazu gehören Infos zu den Tracking-Diensten und Dienstleistern, die Cookies verarbeiten. Auch Cookie-Name, Cookie-Lebensdauer sowie Art und Funktionsweise müssen angegeben werden.

Risiken beim Cookie-Einsatz

Neben rechtlichen Aspekten gibt es noch verschiedene Risiken, die beim Einsatz von Cookies entstehen. Vor allem in der Vergangenheit wurden über Cookies viele Sicherheitslücken entdeckt, die Angreifer ausnutzten. Die bekanntesten Risiken sind:

• Man-in-middle: Hier schaltet sich ein Angreifer zwischen 2 Kommunikationsparteien (in unserem Fall Browser und Server). Die ausgetauschten Informationen werden vom Angreifer abgefangen und geändert. Über Cookies können dann Informationen vom Server abgefangen, modifiziert und dann an den Browser gesendet werden oder umgekehrt. Dies geschieht vor allem über HTTP-Verbindungen. Ein wichtiger Lösungsschritt ist die Implementierung von HTTPS. Um die Sicherheit zu erhöhen sollten die Cookies zudem mit dem Secure-Attribut versehen werden.
• XSS (Cross Site Scripting): Hier werden Sicherheitslücken ausgenutzt, indem Skripte eingeschleußt und ausgeführt werden. Das Skript ließt nun Cookies aus und sendet die Informationen zurück an den Angreifer. Hier hilft das HttpOnly-Flag. Dadurch können Cookies von JavaScript nicht mehr ausgelesen werden.
• CSRF (Cross Site Request Forgery): Hier nutzt der Angreifer den Login-Status innerhalb einer Session des Nutzers auf einer vertrauenswürdigen Website. Besucht der Nutzer eine Website des Angreifers, sendet der Angreifer einen Request an die vertrauenswürdige Seite und versucht den Login-Status über Cookies ebenfalls zu bekommen. Dazu gibt es verschiedene Abwehrmaßnahmen.

Cookies einsehen

Welches Cookies eine Website setzt, kann man selbst einsehen. Es gibt verschiedene Browser-Plugins und -Erweiterungen, die das unkompliziert anzeigen können. Um geeignete Tools zu finden, reicht eine Google-Suche mit [browsername plugin cookies]. Über die Entwicklertools, die in jedem gängigen Browser integriert sind, lassen sich die Cookies ebenfalls einsehen. In Chrome navigiert man dazu wie folgt:

1. Website aufrufen
2. Mit F12 in die Developer Console wechseln
3. Tab “Application” aufrufen
4. Im linken Navigationsmenü auf “Cookies” klicken
5. In der darunter aufgeklappten Liste die Domain wählen
6. Auf der rechten Seite werden nun die Cookies aufgelistet

Je Cookie kann man dann verschiedene Daten einsehen. Den Namen, Wert, von welcher Domain der Cookie gesetzt wird, SameSite-Attribut, etc.

Was man im Cookies alles an Informationen schreiben kann, schauen wir uns später an.

Aufbau von Cookies

Bei jedem HTTP-Request tauschen Browser und Server Cookie-Informationen aus. Der Prozess sieht dabei grob wie folgt aus:

• Bei jedem HTTP-Response seitens dem Server geht auch eine Aufforderung einen Cookie zu speichern an den Browser (Header: Set-Cookie)
• Der Browser speichert den Cookie
• Ab diesem Zeitpunkt schickt der Browser bei jedem HTTP-Request, den er an den Server schickt, den Cookie mit (Header: Cookie)

Ein Cookie ist dabei ein Datenpaket und besteht min. aus einem Namen und einem Wert. Zusätzlich können weitere Attribute mitgegeben werden (dazu später mehr).

Alle Angaben im Cookie setzen sich aus einem Key (Name) und Value (Wert) zusammen. Getrennt werden die Angaben mit einem Strichpunkt (;). Hier ein Beispiel eines einfachen Cookies mit Name und Wert:

userid=1234

Wird ein zusätzliches Attribut mitgegeben, wird das mit ; getrennt:

userid=1234; Max-Age=1209600

Hier kommt das Attribut “Max-Age” dazu, welches die Gültigkeitsdauer des Cookies mitgibt. Wird jedoch nur der Name und Wert mitgegeben, dann werden einige Attribute standardmäßig wie folgt gesetzt:

• Ohne Angabe der Gültigkeitsdauer wird es ein Session-Cookie
• Das Cookie wird für die aktuelle Domain gesetzt (Domain-Attribut)
• Das Cookie wird für den aktuellen Pfad gesetzt (Path-Attribut)

Dann gibt es noch das SameSite-Attribut, welches ebenfalls einen Standard-Wert hat, falls es nicht aktiv gesetzt wird. Dieser Standard-Wert ist jedoch abhängig vom Browser. Zu den Cookie-Attributen gibt es gleich mehr Details.

Wie werden Cookies gesetzt?

Es gibt 2 Arten wie Cookies gesetzt und übertragen werden können:

• Über HTTP-Header (server-seitig)
• Über JavaScript (client-seitig)

Über HTTP-Header

Hier werden Cookies über das Backend gesetzt. Bevor die Antwort an den Client geht, werden die Cookie-Daten im Response-Header mitgegeben. Das kann grob über 2 Wege passieren:

• Der Code der verwendeten Backend-Application setzt die Cookie-Werte in den Response. Z.B. über PHP, Python, Java, etc.).
• Der Webserver (Apache oder Nginx) setzt den Cookie im Response.

Mit PHP erfolgt dies über die setcookie()-Funktion. Mit Apache erfolgt es über das Modul mod_headers. Das Ergebnis läuft immer auf das Gleiche hinaus. Im Response-Header wird mitgegeben:

Set-Cookie

Stellt nun der Browser – nachdem er das Cookie erhalten hat – erneut eine Anfragen beim Server, dann schickt der Browser im Request das Cookie mit:

Cookie

Dadurch lässt sich der Nutzer wiedererkennen und bleibt z.B. beim Session-Wechsel weiterhin eingeloggt. Damit die Wiedererkennung stattfinden kann, muss im Cookie natürlich ein Identifier mitgegeben werden. In der Praxis würde also der Server im Response mitschicken:

Set-Cookie: userid=1234

Und der Browser schickt dann beim nächsten Request:

Cookie: userid=1234

Über JavaScript

Cookies können auch über JavaScript gesetzt werden. Zudem ist es möglich server-seitig gesetzte Cookies client-seitig über JavaScript auszulesen und mit weiteren Informationen zu erweitern bevor sie wieder an den Server geschickt werden.

Der Zugriff auf Cookies erfolgt mit JavaScript mittels:

document.cookie

Ausgegeben wird das Cookie als langer String. Beispiel:

userid=1234;Max-Age=1209600;expires=Mon, 01 Jun 2020 20:00:00 GMT;Path=/kontakt/;Domain=demirjasarevic.com

Um einen neuen Cookie zu setzen, kann man seine gewünschten Werte einfach zuweisen:

document.cookie = "name=cookie;Path=/abc/";

In der Praxis definiert man dazu eher eine Funktion, die die notwendigen Werte setzt.

Wie arbeiten Cookies?

Gehen wir von einer Seite aus, die einen Login erfordert. Diese Seite sieht wie folgt aus:

Dies ist auch ein klassisches Szenario eines Cookies. Aufgabe ist es den Login-Status während der Sitzung aufrecht zu erhalten. Gibt der Nutzer den Namen und das Passwort ein, passiert im Hintergrund folgendes:

1. Der Browser sendet einen HTTP-Request an den Server. Im Request sind die Login-Daten verschlüsselt enthalten.
2. Sind die Daten beim Server angekommen, prüft dieser ob Login-Daten stimmen, in dem der Server die Daten mit einer Datenbank abgleicht. Ist der Abgleich erfolgreich, schickt der Server einen HTTP-Response. Dieser Response enthält den Set-Cookie-Header mit einem Wert.
3. Der Browser erhält nun die Antwort und der Nutzer wird eingeloggt. Gleichzeitig speichert der Browser den Cookie von der angefragten Website im eigenen Speicher ab.
4. Surft nun der Nutzer weiter im Login-Bereich und löst einen weiteren Seitenaufruf aus, dann sendet der Browser wieder eine Anfrage an den Server. In der Anfrage wird der Cookie aus dem Speicher mitgeschickt.
5. Der Server gleicht nun die Cookie-Informationen ab und weiß, dass der Nutzer schon eingeloggt ist. Nun wird die Antwort geschickt.
6. Der Browser erhält die Seite und der Nutzer bleibt weiterhin eingeloggt.

Nachfolgend eine Grafik wie das visuell aussieht inkl. den Header-Informationen in den einzelnen Kästen. Aus Platzgründen habe ich die Header-Angaben ganz knapp gehalten. In der Praxis findet man hier deutlich mehr Informationen. Zudem noch eine Erklärung zu der HTTP-Anfrage und -Antwort:

• Die erste Zeile ist der Request (beim Request) bzw. Status (bei der Antwort)
• Die Zeile mit “Host” ist beim Request der HTTP-Request-Header; bei der Antwort ist es der HTTP-Response-Header. Hier ist auch “Set-Cookie” dann zu finden.
• Dann kommt beim beiden eine leere Zeile, um Header vom Body zu trennen
• Am Ende ist noch der Request Body bzw. Response Body

Cookie-Attribute erklärt

Um die einzelnen Attribute zu erklären, nehmen wir als Ausgangspunkt folgendes Cookie:

userid=1234

Das Cookie hat also den Namen “userid” und besitzt dabei den Wert 1234. Nun können mit einem Strichpunkt (;) getrennt weitere Attribute mitgegeben werden:

• Max-Age
• expires
• Path
• Domain
• Secure
• HttpOnly
• SameSite

Max-Age

Mit Max-Age wird die maximale Zeitdauer – angefangen beim Zeitpunkt des Requests – definiert. Der Wert wird dabei in Sekunden angegeben.

userid=1234; Max-Age=1209600

1209600 Sekunden sind 336 Stunden, also 14 Tage. Das Cookie läuft also nach 2 Wochen ab. Neben Max-Age gibt es noch das Attribut expires für Gültigkeitsangaben.

expires

Anders als bei Max-Age wird bei expires nicht die Zeitdauer – ausgehend vom Zeitpunkt des Requests – angegeben, sondern ein konkretes Datum in der Zukunft:

userid=1234; Max-Age=1209600; expires=Mon, 01 Jun 2020 20:00:00 GMT

Laut expires läuft das Cookie am 01. Juni 2020 um 20 Uhr ab. Das wäre aber nur der Fall, wenn expires ohne Max-Age mitgegeben wird. Stehen beide Werte im Cookie, dann bekommt Max-Age den Vorrang.

Path

Das Path-Attribut ist eine Möglichkeit den Scope des Cookies zu definieren. Eine weitere Möglichkeit wäre das Domain-Attribut (dazu gleich mehr). Das Path-Attribut sieht wie folgt aus:

userid=1234; Max-Age=1209600; expires=Mon, 01 Jun 2020 20:00:00 GMT; Path=/kontakt/

Mit dem Path (Pfad) wird das Cookie auf dem Pfad innerhalb des Hosts eingeschränkt. Selbst wenn ein weiterer Pfad auf der gleichen Domain liegt, können die Daten nicht ausgetauscht werden. Wird Path weggelassen, dann ist der Default-Wert /. Setzen wir als Path “/kontakt/”, dann werden Cookies auch für folgende Seiten ausgelesen:

• /kontakt/adresse/
• /kontakt/anfahrt/
• usw.

Domain

Mit dem Domain-Attribut regelt man, ob der Browser das Cookie a) akzeptieren soll und b) wo das Cookie zurückgeschickt wird. Dieses Attribut wird wie folgt gesetzt:

userid=1234; Max-Age=1209600; expires=Mon, 01 Jun 2020 20:00:00 GMT; Path=/kontakt/; Domain=demirjasarevic.com

Hier kann es nun zu verschiedenen Fällen kommen:

• Gehen wir davon aus ein Nutzer ruft “domain1.com” auf. Der Server antwortet und hat im Domain-Attribut “domain2.com” definiert. Der Browser wird dieses Cookie blockieren, da es kein Matching gibt.
• Oder ein Nutzer ruft “subdomain1.domain.com” auf. Der Server antwortet und hat im Domain-Attribut “subdomain2.domain.com” definiert. Auch hier wird der Browser das Cookie blockieren, da kein Matching vorhanden ist.
• Ruft der Nutzer jedoch “subdomain1.domain.com” auf und hat der Server im Domain-Attribut “subdomain1.domain.com”, dann wird das Setzen des Cookies erlaubt. Auch wird der Browser die Cookie-Informationen wieder an den Server schicken können.
• Ruft der Nutzer “subdomain1.domain.com” auf und hat der Server im Domain-Attribut “domain.com”, dann wird das Cookie ebenfalls erlaubt. Hier gibt es auf Host-Level (also domain.com) ein Matching.

Vor allem letzter Punkt kann hilfreich sein, wenn über Subdomains hinweg Cookie-Daten zur Verfügung stehen müssen. Gleichzeitig muss man aber auch ganz genau darauf achten, mit welchen Subdomains (falls sie nicht einem selbst gehören) man auf dem gleichen Host Cookie-Daten austauschen möchte.

Beim Domain-Attribut muss noch die Public Suffix List beachtet werden. Selbst wenn die angefragte Ressource mit dem Domain-Attribut übereinstimmt, können die Cookies dennoch blockiert werden, wenn die Domain in der Public Suffix List enthalten ist. Mehr dazu gibt es hier:

• Public Suffix List

Wird das Domain-Attribut nicht gesetzt, dann wird der Host der Seite im Domain-Attribut gesetzt.

Secure

Mit dem Secure-Attribut werden die Cookies nur akzeptiert, wenn sie über HTTPS kommen.

userid=1234; Max-Age=1209600; expires=Mon, 01 Jun 2020 20:00:00 GMT; Path=/kontakt/; Domain=demirjasarevic.com; Secure

HttpOnly

Damit wird geregelt, ob das server-seitig erzeugte Cookie von JavaScript mittels document.cookie gelesen werden darf.

userid=1234; Max-Age=1209600; expires=Mon, 01 Jun 2020 20:00:00 GMT; Path=/kontakt/; Domain=demirjasarevic.com; Secure; HttpOnly

Falls dieses Flag gesetzt wird, dann kann man client-seitig darauf nicht zugreifen. Versucht man also dann in der Console mittels document.cookie darauf zuzugreifen, bekommt man einen leeren String. Möchte man im Browser dennoch die gesetzten Cookies einsehen, müsste man im Tab “Application” nachsehen.

SameSite

Um das SameSite-Attribut zu verstehen, müssen wir etwas ausholen und die Themen First- und Third-Party-Cookies zunächst beleuchten. Gehen wir daher vom folgenden Fall aus:

1. Nutzer besucht eigene-domain.com
2. Der Server antwortet und schickt “Set-Cookie” mit
3. Das Cookie wird im Browser abgespeichert
4. Surft der Nutzer auf der gleichen Domain weiter, dann schickt der Browser die Cookie-Informationen wieder an den Server, usw.

Das wäre der First-Party-Kontext. Browser und Server tauschen ihre Cookie-Informationen aus, da dies alles auf der gleichen Domain, die der Nutzer gerade besucht, passiert.

Erweitern wir das soeben dargestellte Beispiel etwas. Nehmen wir an, dass auf der Website ein Skript oder Bild eingebunden ist, welches nicht von eigene-domain.com geladen wird. Die Ressource wird im Hintergrund von fremde-domain.com geladen. Der Ablauf wäre dann wie folgt:

1. Nutzer besucht eigene-domain.com
2. Der Server antwortet und schickt “Set-Cookie” für eigene-domain.com mit
3. Das Cookie wird im Browser abgespeichert
4. Auf der Seite ist ein Skript von fremde-domain.com eingebunden
5. Die Ressource wird vom Browser bei fremde-domain.com angefordert
6. fremde-domain.com antwortet und liefert das Skript aus
7. Gleichzeitig schickt fremde-domain.com im Header ein Cookie mit, welches der Browser bei sich speichert
8. Surft der Nutzer auf der Domain weiter, dann schickt der Browser die Cookie-Informationen wieder an die jeweiligen Server, usw.

Der Cookie von eigene-domain.com wäre hier wie vorhin erwähnt im First-Party-Kontext. Der Cookie von fremde-domain.com wäre hier im Third-Party-Kontext (dagegen geht z.B. ITP vor).

Was hat das mit dem SameSite-Attribut zu tun? Mit SameSite lässt sich nun definieren, ob die Cookies auf einen First-Party-Kontext beschränkt werden sollten. Das SameSite-Attribut bekam lange Zeit nicht sehr viel Beachtung. Beim Auslassen des Attributs erlaubte man das Senden des Cookies in allen Kontexten. Als das Chrome-Team 2019 eine verbesserte Privatsphäre ankündigte, änderte sich die Handhabung. Das SameSite-Update sollte zunächst mit Chrome 80 eingeführt werden. Aufgrund der Corona-Krise wurde es für Chrome 84 aufgeschoben. Chrome verlangt ab da von Entwicklern das SameSite-Attribut aktiv bei Drittanbieter-Cookies zu setzen. Sollte es nicht gesetzt werden, dann werden Third-Party-Cookies standardmäßig mit SameSite=Lax behandelt. Ziel ist es die Cookie-Sicherheit zu erhöhen und CSFR-Attacken vorzubeugen.

Was bedeutet SameSite=Lax? Grundsätzlich kann das Attribut 3 Einstellungen annehmen:

• Strict: Mit Strict wird der Cookie nur gesendet, wenn er im First-Party-Kontext ist. Sobald die URL in der Adresszeile mit der URL im Cookie übereinstimmt, gibt es hier grünes Licht.
• Lax: Mit Lax wird ebenfalls kein Third-Party-Kontext erlaubt. Ist auf Domain A ein Bild von Domain B eingebunden, dann löst Doamin A einen Request an Domain B aus. Liefert Domain B das Bild aus sendet einen Cookie mit, dann wird dieser (zunächst) blockiert. Ist aber unter dem Bild ein Link zu Domain B eingebunden und klickt der Nutzer drauf und gelangt so zur Domain B, dann wird der Cookie im Header akzeptiert. Zu beachten ist, dass Lax über sichere HTTP-Methoden funktioniert. Also GET, HEAD, OPTIONS und TRACE. Über POST werden hingegen keine Cookies geschickt.
• None: Mit dem Setzen von “None” wird der Third-Party-Kontext aufrechterhalten. Zusätzlich muss das Secure-Attribut gesetzt werden.

Bis zum Chrome-Update führte das Auslassen des Attributs dazu, dass man Cookies im Third-Party-Kontext zugelassen hatte. Ab Chrome 84 ist SameSite=Lax der Standard-Wert, wenn das Attribut nicht gesetzt wird. Möchte man weiterhin einen Third-Party-Kontext zulassen, muss man als Webmaster mit SameSite=None aktiv ein “Opt-In” durchführen. Gleichzeitig muss aber auch das Secure-Attribut gesetzt werden. Vor allem wenn man Widgets über iFrames in fremde Seiten einbindet oder Cookies über fremde Websites verschicken möchte, sollte man als Anbieter dieses Attribut setzen.

Was man sonst noch über Cookies wissen sollte

• Die Größe von Cookies ist auf max. 4 KB beschränkt.
• Ein Server kann nicht unendlich viele Cookies an einen Client senden. Die Browser schränken dies ein, um keinen unnötig hohen Speicherplatzbedarf zu erzeugen.