SameSite-Cookies

Schützen Sie Ihre Website, indem Sie sich damit vertraut machen, wie Sie Ihre websiteübergreifenden Cookies explizit markieren.

Jedes Cookie enthält ein Schlüssel/Wert-Paar sowie eine Reihe von Attributen, die steuern, wann und wo das Cookie verwendet wird.

Mit der Einführung des Attributs SameSite (in RFC6265bis definiert) können Sie angeben, ob Ihr Cookie auf einen eigenen Kontext oder auf den Kontext derselben Website beschränkt werden soll. Es ist hilfreich, genau zu verstehen, was „Website“ hier bedeutet. Die Website ist die Kombination aus dem Domain-Suffix und dem Teil der Domain unmittelbar davor. Die Domain www.web.dev ist beispielsweise Teil der Website web.dev.

Die öffentliche Suffixliste definiert dies, es gelten also nicht nur Top-Level-Domains wie .com, sondern auch Dienste wie github.io. Dadurch können your-project.github.io und my-project.github.io als separate Websites gezählt werden.

Wenn Sie das Attribut SameSite für Cookies einführen, können Sie dieses Verhalten auf drei verschiedene Arten steuern. Sie können das Attribut nicht angeben oder Strict oder Lax verwenden, um das Cookie auf Anfragen derselben Website zu beschränken.

Wenn Sie SameSite auf Strict setzen, wird das Cookie nur in einem Erstanbieterkontext gesendet. Für den Nutzer wird das Cookie nur gesendet, wenn die Website für das Cookie mit der Website übereinstimmt, die aktuell in der URL-Leiste des Browsers angezeigt wird. Wenn das promo_shown-Cookie also so gesetzt ist:

Set-Cookie: promo_shown=1; SameSite=Strict

Wenn der Nutzer Ihre Website besucht, wird das Cookie erwartungsgemäß mit der Anfrage gesendet. Wenn Sie jedoch einem Link zu Ihrer Website folgen, z. B. von einer anderen Website oder über die E-Mail eines Freundes, wird das Cookie bei dieser ersten Anfrage nicht gesendet. Dies ist sinnvoll, wenn Sie Cookies für Funktionen haben, die sich immer hinter einer anfänglichen Navigation befinden, z. B. wenn ein Passwort geändert oder ein Kauf getätigt wird, aber für promo_shown zu restriktiv sind. Wenn deine Leser dem Link zu der Website folgen, möchten sie, dass das Cookie gesendet wird, damit ihre Präferenz angewendet werden kann.

Hier kommt SameSite=Lax ins Spiel, indem das Cookie mit diesen Navigationen der obersten Ebene gesendet wird. Nehmen wir wieder das obige Beispiel mit Katzenartikeln, in dem eine andere Website auf Ihre Inhalte verweist. Diese nutzen direkt Ihr Foto der Katze und bieten einen Link zum Originalartikel.

<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 deinem Blog folgt, enthält diese Anfrage das Cookie. Daher ist Lax eine gute Wahl für Cookies, die die Anzeige der Website beeinflussen, wobei Strict nützlich für Cookies ist, die sich auf Aktionen beziehen, die dein Nutzer ausführt.

Schließlich gibt es noch die Möglichkeit, den Wert nicht anzugeben. Bisher wurde implizit angegeben, dass das Cookie in allen Kontexten gesendet werden soll. Im aktuellen Entwurf von RFC6265bis wurde dies durch die Einführung des neuen Werts SameSite=None explizit gemacht. Das bedeutet, dass Sie mit None deutlich angeben können, dass das Cookie absichtlich an einen Drittanbieter gesendet werden soll.

Drei Cookies, die je nach Kontext mit „Keine“, „Lax“ oder „Strikt“ gekennzeichnet sind
Markieren Sie den Kontext eines Cookies explizit als None, Lax oder Strict.

Änderungen am Standardverhalten ohne SameSite

Das Attribut SameSite wird zwar allgemein unterstützt, es wird jedoch von Entwicklern leider noch nicht weit verbreitet. Die offene Standardeinstellung, Cookies überall zu senden, bedeutet, dass alle Anwendungsfälle funktionieren, Nutzer aber anfällig für CSRF und unbeabsichtigte Datenlecks sind. Damit Entwickler ihre Absichten mitteilen und Nutzer sicherer machen können, werden im IETF-Vorschlag Inkrementelle Better Cookies zwei wichtige Änderungen erläutert:

  • Cookies ohne SameSite-Attribut werden als SameSite=Lax behandelt.
  • Cookies mit SameSite=None müssen auch Secure angeben. Sie erfordern also einen sicheren Kontext.

Chrome implementiert dieses Standardverhalten ab Version 84. In Firefox können sie ab Firefox 69 getestet werden und werden in Zukunft als Standardverhalten festgelegt. Wenn Sie dieses Verhalten in Firefox testen möchten, öffnen Sie about:config und legen Sie network.cookie.sameSite.laxByDefault fest. Edge plant außerdem, sein Standardverhalten zu ändern.

Standardmäßig SameSite=Lax

Kein Attribut festgelegt
Set-Cookie: promo_shown=1

Beim Senden eines Cookies ohne angegebenes SameSite-Attribut...

Standardverhalten angewendet
Set-Cookie: promo_shown=1; SameSite=Lax

Der Browser behandelt dieses Cookie so, als wäre SameSite=Lax angegeben.

Damit soll ein sichererer Standardwert angewendet werden. Idealerweise sollten Sie jedoch ein explizites SameSite-Attribut festlegen, anstatt sich darauf zu verlassen, dass der Browser das für Sie anwendet. Das macht das Cookie deutlich und erhöht die Wahrscheinlichkeit, dass die Nutzung in allen Browsern einheitlich ist.

SameSite=None muss sicher sein

Abgelehnt
Set-Cookie: widget_session=abc123; SameSite=None

Das Setzen eines Cookies ohne Secure wird abgelehnt.

Angenommen
Set-Cookie: widget_session=abc123; SameSite=None; Secure

Achte darauf, dass du SameSite=None mit dem Attribut Secure kombinierst.

Du kannst dieses Verhalten ab Chrome 76 testen, indem du about://flags/#cookies-without-same-site-must-be-secure aktivierst, und in Firefox 69 in about:config, indem du network.cookie.sameSite.noneRequiresSecure festlegst.

Dies sollten Sie anwenden, wenn Sie neue Cookies festlegen und vorhandene Cookies aktiv aktualisieren, auch wenn sie ihr Ablaufdatum nicht erreichen.

Beide Änderungen sind abwärtskompatibel mit Browsern, die die vorherige Version des SameSite-Attributs korrekt implementiert haben oder sie einfach überhaupt nicht unterstützen. Wenn Sie diese Änderungen auf Ihre Cookies anwenden, geschieht dies explizit und nicht durch das Standardverhalten des Browsers. Ebenso sollten Clients, die SameSite=None noch nicht erkennen, dies ignorieren und fortfahren, als ob das Attribut nicht festgelegt wäre.

Weitere Informationen dazu, wie Sie Ihre Cookies aktualisieren, um diese Änderungen an SameSite=None erfolgreich zu verarbeiten, und die Unterschiede im Browserverhalten finden Sie im Folgeartikel SameSite-Cookie-Rezepte.

Vielen Dank für die Beiträge und das Feedback von Lily Chen, Malte Ubl, Mike West, Rob Dodson, Tom Steiner und Vivek Sekhar.

Cookie-Hero-Image von Pille-Riin Priske auf Unsplash