SameSite-Cookies

Rowan Merewood

Unterstützte Browser

  • Chrome: 51.
  • Edge: 16.
  • Firefox: 60.
  • Safari: 13.

Quelle

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

Mit dem neuen SameSite-Attribut (definiert in RFC6265bis) können Sie angeben, ob Ihr Cookie auf einen Erstanbieter- oder einen Website-Kontext beschränkt ist. Es ist hilfreich zu verstehen, was hier genau unter „Website“ verstanden wird. Die Website besteht aus dem Domainsuffix und dem Teil der Domain davor. Die Domain www.web.dev ist beispielsweise Teil der Website web.dev.

Wichtiger Begriff: Wenn sich der Nutzer auf www.web.dev befindet und ein Bild von static.web.dev anfordert, handelt es sich um eine Anfrage auf derselben Website.

In der Liste der öffentlichen Suffixe wird festgelegt, welche Seiten zu derselben Website gehören. Sie hängt nicht nur von Top-Level-Domains wie .com ab, sondern kann auch Dienste wie github.io umfassen. So können your-project.github.io und my-project.github.io als separate Websites gezählt werden.

Wichtiger Begriff: Wenn sich der Nutzer auf your-project.github.io befindet und ein Bild von my-project.github.io anfordert, handelt es sich um eine websiteübergreifende Anfrage.

Cookie-Nutzung mit dem SameSite-Attribut angeben

Mit dem Attribut SameSite in einem Cookie können Sie dieses Verhalten auf drei verschiedene Arten steuern. Sie können das Attribut auch nicht angeben oder Strict oder Lax verwenden, um das Cookie auf Anfragen innerhalb der Website zu beschränken.

Wenn Sie SameSite auf Strict festlegen, kann Ihr Cookie nur in einem Kontext mit selbst erhobenen Daten gesendet werden, d. h., wenn die Website für das Cookie mit der Website übereinstimmt, die in der Adressleiste des Browsers angezeigt wird. Wenn das promo_shown-Cookie so festgelegt ist:

Set-Cookie: promo_shown=1; SameSite=Strict

Wenn sich der Nutzer auf Ihrer Website befindet, wird das Cookie wie erwartet mit der Anfrage gesendet. Wenn der Nutzer jedoch über einen Link von einer anderen Website zu Ihrer Website gelangt, wird das Cookie bei dieser ersten Anfrage nicht gesendet. Das ist gut für Cookies, die sich auf Funktionen beziehen, die immer erst nach einer ersten Navigation aufgerufen werden, z. B. zum Ändern eines Passworts oder zum Kaufen. Für ein Cookie wie promo_shown ist diese Definition jedoch zu restriktiv. Wenn der Leser dem Link zur Website folgt, möchte er, dass das Cookie gesendet wird, damit seine Einstellungen angewendet werden können.

SameSite=Lax ermöglicht es dem Browser, das Cookie mit diesen Navigationen auf oberster Ebene zu senden. Wenn beispielsweise eine andere Website auf die Inhalte Ihrer Website verweist, indem sie Ihr Katzenfoto verwendet und einen Link zu Ihrem Artikel angibt, sieht das so aus:

<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>

Wenn ein Cookie auf Lax gesetzt ist:

Set-Cookie: promo_shown=1; SameSite=Lax

Wenn der Browser amazing-cat.png für den Blog der anderen Person anfordert, sendet Ihre Website das Cookie nicht. Wenn der Leser jedoch den Link zu cat.html auf deiner Website folgt, enthält diese Anfrage das Cookie.

Wir empfehlen, SameSite auf diese Weise zu verwenden und Cookies, die sich auf die Websiteanzeige auswirken, auf Lax und Cookies im Zusammenhang mit Nutzeraktionen auf Strict festzulegen.

Sie können SameSite auch auf None festlegen, um anzugeben, dass das Cookie in allen Kontexten gesendet werden soll. Wenn Sie einen Dienst bereitstellen, der von anderen Websites genutzt wird, z. B. Widgets, eingebettete Inhalte, Affiliate-Programme, Werbung oder die Anmeldung auf mehreren Websites, verwenden Sie None, um Ihre Absicht klar zu formulieren.

Drei Cookies, die je nach Kontext als „Kein“, „Lax“ oder „Streng“ gekennzeichnet sind
Den Kontext eines Cookies explizit als None, Lax oder Strict kennzeichnen.

Änderungen am Standardverhalten ohne SameSite

Unterstützte Browser

  • Chrome: 80.
  • Edge: 86.
  • Firefox: hinter einer Flagge.
  • Safari: Nicht unterstützt.

Das SameSite-Attribut wird zwar weithin unterstützt, aber nicht häufig verwendet. Wenn in der Vergangenheit Cookies ohne SameSite gesetzt wurden, wurden sie standardmäßig in allen Kontexten gesendet. Das machte Nutzer anfällig für CSRF-Angriffe und unbeabsichtigte Datenlecks. Um Entwickler dazu anzuregen, ihre Absicht zu erklären und Nutzern eine sicherere Nutzung zu ermöglichen, werden im IETF-Vorschlag Incrementally Better Cookies (schrittweise bessere Cookies) zwei wichtige Änderungen beschrieben:

  • Cookies ohne SameSite-Attribut werden als SameSite=Lax behandelt.
  • Für Cookies mit SameSite=None muss auch Secure angegeben werden. Das bedeutet, dass ein sicherer Kontext erforderlich ist.

Beide Änderungen sind abwärtskompatibel mit Browsern, die die vorherige Version des SameSite-Attributs korrekt implementiert haben, sowie mit Browsern, die frühere SameSite-Versionen nicht unterstützen. Sie sollen die Abhängigkeit von Entwicklern vom Standardverhalten von Browsern verringern, indem das Cookie-Verhalten und die beabsichtigte Verwendung explizit gemacht werden. Clients, die SameSite=None nicht erkennen, sollten es ignorieren.

SameSite=Lax standardmäßig

Wenn Sie ein Cookie senden, ohne das SameSite-Attribut anzugeben, behandelt der Browser dieses Cookie so, als wäre es auf SameSite=Lax gesetzt. Wir empfehlen jedoch weiterhin, SameSite=Lax explizit festzulegen, damit die Nutzererfahrung in verschiedenen Browsern einheitlich ist.

SameSite=None muss sicher sein

Wenn Sie websiteübergreifende Cookies mit SameSite=None erstellen, müssen Sie sie auch auf Secure festlegen, damit der Browser sie akzeptiert:

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

Sie können dieses Verhalten ab Chrome 76 testen, indem Sie about://flags/#cookies-without-same-site-must-be-secure aktivieren. In Firefox 69 können Sie network.cookie.sameSite.noneRequiresSecure unter about:config festlegen.

Wir empfehlen außerdem, vorhandene Cookies so schnell wie möglich auf Secure umzustellen. Wenn Sie Dienste nutzen, die Drittanbieterinhalte auf Ihrer Website bereitstellen, müssen Sie dafür sorgen, dass Ihr Dienstanbieter seine Cookies aktualisiert. Außerdem müssen Sie alle Snippets oder Abhängigkeiten auf Ihrer Website aktualisieren, damit das neue Verhalten verwendet wird.

Weitere Informationen zum Aktualisieren Ihrer Cookies, damit diese Änderungen an SameSite=None und die Unterschiede im Browserverhalten ordnungsgemäß verarbeitet werden, 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