SameSite-Cookies erklärt
Sichern Sie Ihre Website, indem Sie lernen, wie Sie Ihre Cross-Site-Cookies explizit kennzeichnen.
Cookies sind eine der verfügbaren Methoden, um Websites einen dauerhaften Status hinzuzufügen. Im Laufe der Jahre haben ihre Funktionen zugenommen und sie sind weiterentwickelt worden, wobei allerdings auch einige problematische Altlasten für die Plattform entstanden sind. Um dem entgegenzuwirken, ändern Browser (einschließlich Chrome, Firefox und Edge) ihr Verhalten und setzen datenschutzfreundlichere Standardeinstellungen durch.
Jedes Cookie ist ein key=value
-Paar mit einer Reihe von Attributen, die steuern, wann und wo dieses Cookie verwendet wird. Sie haben diese Attribute wahrscheinlich bereits verwendet, um Dinge wie Ablaufdaten festzulegen oder anzugeben, dass das Cookie nur über HTTPS gesendet werden soll. Server setzen Cookies, indem sie in ihrer Antwort den treffend benannten Set-Cookie
-Header senden. Für alle Details können Sie sich das Dokument RFC6265bis durchlesen, aber hier vorerst eine kurze Erinnerung.
Angenommen, Sie haben einen Blog, in dem Sie Ihren Benutzern eine „Neuigkeiten“-Werbeaktion anzeigen möchten. Benutzer können die Werbeaktion ausblenden und sehen sie dann für eine Weile nicht mehr. Sie können diese Einstellung in einem Cookie speichern, den sie in einem Monat (2.600.000 Sekunden) ablaufen lassen und eine Übertragung ausschließlich über HTTPS zulassen. Dieser Header würde so aussehen:
Set-Cookie: promo_shown=1; Max-Age=2600000; Secure

Set-Cookie
-Headers.Wenn sich Ihre Besucher eine Seite ansehen, die diese Anforderungen erfüllt, z. B. wenn eine sichere Verbindung besteht und das Cookie weniger als einen Monat alt ist, senden die Browser diesen Header in der Anfrage:
Cookie: promo_shown=1

Cookie
-Header zurück.Sie können die für diese Site verfügbaren Cookies auch per JavaScript mit document.cookie
hinzufügen und lesen. Durch eine Zuweisung an document.cookie
wird ein Cookie mit diesem Schlüssel erstellt oder überschrieben. Sie können beispielsweise Folgendes in der JavaScript-Konsole Ihres Browsers versuchen:
→ document.cookie = "promo_shown=1; Max-Age=2600000; Secure"
← "promo_shown=1; Max-Age=2600000; Secure"
Beim Lesen von document.cookie
werden alle im aktuellen Kontext zugänglichen Cookies ausgegeben, wobei jedes Cookie durch ein Semikolon getrennt ist:
→ document.cookie;
← "promo_shown=1; color_theme=peachpuff; sidebar_loc=left"

document.cookie
auf Cookies zugreifen.Wenn Sie dies auf einer Auswahl beliebter Websites ausprobieren, werden Sie feststellen, dass die meisten von ihnen deutlich mehr als nur drei Cookies setzen. In den meisten Fällen werden diese Cookies bei jeder einzelnen Anfrage an eine dieser Domains gesendet, was eine Reihe von Auswirkungen hat. Die Upload-Bandbreite Ihrer Benutzer ist oft stärker eingeschränkt als die Download-Bandbreite, sodass der Overhead für alle ausgehenden Anfragen die Zeit bis zum ersten empfangenen Byte verzögert. Gehen Sie beim Festlegen der Anzahl und Größe der von Ihnen gesetzten Cookies zurückhaltend vor. Verwenden Sie das Max-Age
-Attribut, um sicherzustellen, dass Cookies nicht länger als nötig vorhanden bleiben.
Was sind Erstanbieter- und Drittanbieter-Cookies? #
Wenn Sie einer Auswahl von Webseiten zurückkehren, die Sie bereits zuvor besucht haben, dann ist Ihnen wahrscheinlich aufgefallen, dass Cookies für eine Vielzahl von Domains vorhanden sind, und nicht nur für die, die Sie gerade besuchen. So werden Cookies für die Domain der aktuell besuchten und in der Adresszeile des Browsers angezeigten Seite, als Erstanbieter-Cookies bezeichnet. Cookies von anderen Domains als der aktuellen Webseite werden als Drittanbieter-Cookies bezeichnet. Dies sind keine absoluten Bezeichnungen, sondern sie sind relativ zum Kontext des Benutzers aufzufassen. Ein und derselbe Cookie kann entweder ein Erstanbieter- oder ein Drittanbieter-Cookie sein, je nachdem, auf welcher Website sich der Benutzer gerade befindet.
Führen wir einmal das oben angefangene Beispiel weiter, und nehmen an, einer Ihrer Blog-Posts würde unter /blog/img/amazing-cat.png
gehostet und ein Bild einer besonders tollen Katze enthalten. Weil es ein so tolles Bild ist, verwendet es eine andere Person direkt auf ihrer eigenen Website. Wenn ein Besucher Ihren Blog besucht hat und der Cookie die promo_shown
vorhanden ist, dann wird, wenn sie amazing-cat.png
auf der Website der anderen Person betrachten, das Cookie für das Bild in der Anfrage mitübertragen. Dies ist für niemanden besonders nützlich, da promo_shown
für nichts auf der Webseite dieser anderen Person verwendet wird, es fügt der Anfrage lediglich Overhead hinzu.
Wenn dies also ein unbeabsichtigter Effekt ist, warum sollten Sie das tun? Dieser Mechanismus ermöglicht es Webseiten, Ihren Zustand beizubehalten, wenn sie in einem Drittanbieterkontext verwendet werden. Wenn Sie beispielsweise ein YouTube-Video auf Ihrer Website einbetten, sehen Besucher im Player die Option „Später ansehen“. Ist Ihr Besucher bereits bei YouTube angemeldet, wird diese Sitzung im eingebetteten Player durch einen Drittanbieter-Cookie zur Verfügung gestellt. Dies bedeutet, dass die Schaltfläche „Später ansehen“ das Video in einem Schritt speichert, anstatt ihn zur Anmeldung aufzufordern oder von Ihrer Seite weg zu YouTube zu navigieren.
Eine der kulturellen Eigenschaften des Webs ist, dass es in der Regel offen ist. Dies ist einer der Gründe, aus denen so vielen Menschen ermöglicht wurde, dort ihre eigenen Inhalte und Apps zu erstellen. Andererseits hat dies jedoch auch eine Reihe von Sicherheits- und Datenschutzbedenken mit sich gebracht. Cross-Site Request Forgery-Angriffe (CSRF) beruhen darauf, dass Cookies für alle Anfragen mit beliebigen Zielen angehängt werden, unabhängig davon, wer diese Anfragen initiiert. Wenn Sie beispielsweise evil.example
besuchen, kann diese Seite Anfragen für your-blog.example
auslösen und Ihr Browser würde dazu ohne weiteres die zugehörigen Cookies anhängen. Wenn Ihr Blog also nicht sicherstellt, dass diese Anfragen korrekt validiert werden, dann kann evil.example
Aktionen wie das Löschen von Beiträgen oder das Hinzufügen eigener Inhalte auslösen.
Benutzer werden sich auch immer mehr bewusst, wie Cookies verwendet werden können, um ihre Aktivitäten über mehrere Webseiten nachzuverfolgen. Bisher gab es für Sie jedoch keine Möglichkeit, Ihre Absicht mit dem Cookie explizit anzugeben. Ihr promo_shown
-Cookie sollte nur in einem Erstanbieterkontext gesendet werden, während mit einem Sitzungscookie für ein Widget, das auf anderen Webseiten eingebettet werden soll, eine klare Absicht besteht, den Anmeldestatus in einem Drittanbieterkontext bereitzustellen.
Geben Sie die Cookie-Verwendung explizit mit dem Attribut SameSite
an #
Durch die Einführung des SameSite
-Attributs (definiert in RFC6265bis) können Sie angeben, ob die Verwendung Ihres Cookies auf einen Erstanbieter- oder Same-Site-Kontext beschränkt werden soll. Es ist hilfreich, genau zu verstehen, was „Site“ hier bedeutet. Die Site ist die Kombination aus dem Domain-Suffix und dem Teil der Domain direkt davor. So ist beispielsweise die Domain www.web.dev
Teil der web.dev
-Site.
Dies wird mithilfe der öffentlichen Suffixliste definiert, die nicht nur Top-Level-Domains wie .com
, sondern auch Dienste wie github.io
enthält. So wird es ermöglicht, dass your-project.github.io
und my-project.github.io
als separate Sites betrachtet werden können.
Die Einführung des SameSite
Attributs in ein Cookie bietet drei verschiedene Möglichkeiten, dieses Verhalten zu steuern. Sie können das Attribut nicht angeben, oder Sie können Strict
oder Lax
, um das Cookie auf Anfragen derselben Site zu beschränken.
Wenn Sie SameSite
auf Strict
stellen, wird Ihr Cookie nur in einem Erstanbieterkontext gesendet. Aus Benutzersicht wird das Cookie nur gesendet, wenn die Site für das Cookie mit der Site übereinstimmt, die derzeit in der URL-Leiste des Browsers angezeigt wird. Wenn also das promo_shown
-Cookie wie folgt eingestellt wurde:
Set-Cookie: promo_shown=1; SameSite=Strict
Wenn der Benutzer sich auf Ihrer Website aufhält, wird das Cookie wie erwartet mit der Anfrage gesendet. Wenn Sie jedoch einem Link zu Ihrer Site folgen, beispielsweise von einer anderen Site oder über eine E-Mail von einem Freund, wird bei dieser ersten Anfrage kein Cookie gesendet. Dies ist gut, wenn es um Cookies geht, die sich auf Funktionen beziehen, denen immer eine vorherige Navigation vorausgeht, wie zum Beispiel das Ändern eines Passworts oder eine Bestellung, ist jedoch zu restriktiv für promo_shown
. Wenn Ihr Leser dem Link auf die Site folgt, möchte er, dass das Cookie gesendet wird, damit seine Präferenz angewendet werden kann.
Hier kommt SameSite=Lax
zum Zug, indem es erlaubt, dass das Cookie bei dieser Top-Level-Navigation mitgesendet wird. Sehen wir uns das Beispiel mit der Katze aus dem oben stehenden Artikel noch einmal an, bei dem eine andere Website auf Ihren Inhalt verweist. Sie verwenden Ihr Foto der Katze direkt und stellen einen Link zu Ihrem ursprünglichen Artikel bereit.
<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>
Und das Cookie wurde so gesetzt:
Set-Cookie: promo_shown=1; SameSite=Lax
Wenn sich der Leser im Blog der anderen Person befindet, wird das Cookie nicht gesendet, wenn der Browser amazing-cat.png
anfordert. Wenn der Leser jedoch dem Link zu cat.html
in Ihrem Blog folgt, enthält diese Anfrage das Cookie. Dies macht Lax
zu einer guten Wahl für Cookies, die das Aussehen einer Website betreffen, wobei Strict
für Cookies nützlich ist, die Nutzeraktionen betreffen.
Schließlich besteht die Möglichkeit, den Wert nicht anzugeben, was bislang implizit bedeutete, dass das Cookie in allen Kontexten gesendet werden soll. Im neuesten Entwurf von RFC6265bis wird dies durch die Einführung eines neuen Wertes von SameSite=None
explizit festgelegt. Das bedeutet, dass Sie mit None
klar kommunizieren können, dass Sie das Cookie absichtlich im Drittanbieterkontext senden möchten.None
, Lax
oder Strict
an.
Änderungen am Standardverhalten ohne SameSite #
Obwohl das SameSite
-Attribut weithin unterstützt wird, wird es leider nicht von vielen Entwicklern genutzt. Die offene Standardeinstellung, mit der Cookies überall hingesendet werden können, sichert zwar in allen Anwendungsfällen die Funktion, aber die Benutzer sind anfällig für CSRF und unbeabsichtigte Informationslecks. Um Entwickler zu ermutigen, ihre Absicht zu äußern und den Benutzern ein sichereres Erlebnis zu bieten, enthält der IETF-Vorschlag Incrementally Better Cookies zwei wichtige Änderungen:
- Cookies ohne
SameSite
-Attribut werden wie solche mit dem AttributSameSite=Lax
behandelt. - Cookies mit
SameSite=None
müssen auchSecure
angeben, sie erfordern also einen sicheren Kontext.
Chrome implementiert dieses Standardverhalten ab Version 84. Firefox stellt sie zum Testen ab Firefox 69 bereit und wird sie in Zukunft zum Standardverhalten machen. Um dieses Verhalten in Firefox zu testen, öffnen Sie about:config
und legen Sie network.cookie.sameSite.laxByDefault
fest. Auch für Edge ist geplant, das Standardverhalten zu ändern.
SameSite=Lax
in der Standardeinstellung #
No attribute set
Set-Cookie: promo_shown=1
Wenn Sie ein Cookie ohne festgelegtem SameSite
-Attribut senden…
Default behavior applied
Set-Cookie: promo_shown=1; SameSite=Lax
Wird der Browser das Cookie so interpretieren, als wäre SameSite=Lax
angegeben worden.
Obwohl dies als eine sicherere Standardeinstellung gedacht ist, sollten Sie idealerweise dennoch ein explizites SameSite
-Attribut festlegen, anstatt sich darauf zu verlassen, dass der Browser dieses für Sie anwendet. Dies macht Ihre Absicht für das Cookie deutlich und verbessert die Chancen auf ein übereinstimmendes Benutzererlebnis in allen Browsern.
SameSite=None
muss sicher sein #
Rejected
Set-Cookie: widget_session=abc123; SameSite=None
Das Setzen eines Cookies ohne Secure
wird abgelehnt .
Accepted
Set-Cookie: widget_session=abc123; SameSite=None; Secure
Sie müssen sicherstellen, dass Sie SameSite=None
mit dem Attribut Secure
koppeln.
Sie können dieses Verhalten ab Chrome 76 testen, indem Sie about://flags/#cookies-without-same-site-must-be-secure
aktivieren und ab Firefox 69 unter about:config
die Einstellung network.cookie.sameSite.noneRequiresSecure
setzen.
Sie sollten diese Einstellungen beim Setzen neuer Cookies anwenden und vorhandene Cookies aktiv aktualisieren, auch wenn deren Ablaufdatum noch in der Ferne liegt.
Beide Änderungen sind abwärtskompatibel mit Browsern, die die vorherige Version des SameSite
-Attributs korrekt implementiert haben oder es überhaupt nicht unterstützen. Indem Sie diese Änderungen auf Ihre Cookies anwenden, erklären Sie explizit deren beabsichtigte Verwendung, anstatt sich auf das Standardverhalten des Browsers zu verlassen. Ebenso sollten alle Clients, die SameSite=None
noch nicht erkennen, es einfach ignorieren und weiterarbeiten, als ob das Attribut nicht gesetzt wäre.
SameSite
-Cookie-Rezepte #
Weitere Informationen dazu, wie Sie Ihre Cookies genau aktualisieren, um diese Änderungen zu SameSite=None
und den einhergehenden Unterschied im Browserverhalten zu berücksichtigen, finden Sie im Folgeartikel SameSite-Cookie-Rezepte .
Herzlichen Dank für Beiträge und Feedback von Lily Chen, Malte Ubl, Mike West, Rob Dodson, Tom Steiner und Vivek Sekhar
Cookie-Held-Bild von Pille-Riin Priske auf Unsplash