SameSite-Cookies

Rowan Merewood

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

Die Einführung des Attributs SameSite (definiert in RFC6265bis) können Sie angeben, ob Ihr Cookie auf Erstanbieter- oder Website-Kontext zu vergleichen. Es ist hilfreich zu wissen, was genau bedeutet hier. Die Website ist die Kombination aus dem Domain-Suffix und dem Teil der Domain, davor. Die Domain www.web.dev ist beispielsweise Teil der Website web.dev.

Schlüsselbegriff: Wenn der Nutzer auf www.web.dev ist und ein Bild von static.web.dev, das ist eine Anfrage für Gleiche Website.

In der öffentlichen Suffixliste wird definiert, als welche Seiten gezählt werden. sich auf derselben Website befinden. Es hängt nicht nur von Top-Level-Domains wie .com ab, aber auch Dienste wie github.io umfassen. Dies ermöglicht your-project.github.io und my-project.github.io werden als separate Websites gezählt.

Schlüsselbegriff: Wenn der Nutzer auf your-project.github.io ist und ein Bild von my-project.github.io ist eine websiteübergreifende Anfrage.

Verwenden Sie das Attribut SameSite, um die Cookie-Nutzung zu deklarieren

Das Attribut SameSite für ein Cookie bietet drei verschiedene Möglichkeiten, dieses Verhaltens. Sie können sich dafür entscheiden, das Attribut nicht anzugeben, oder Strict oder Lax, um das Cookie auf SameSite-Anfragen zu beschränken.

Wenn Sie SameSite auf Strict setzen, kann Ihr Cookie nur innerhalb eines Erstanbieter-Kontext wenn die Website für das Cookie mit der angezeigten Website übereinstimmt in die Adressleiste des Browsers ein. Wenn also das Cookie promo_shown so gesetzt 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. Klickt der Nutzer jedoch von einem anderen Link zu Ihrer Website, wird das Cookie bei dieser ursprünglichen Anfrage nicht gesendet wird. Dies ist gut für Cookies für Funktionen, die immer hinter einer Anfangsbuchstabe z. B. wenn Sie ein Passwort ändern oder etwas kaufen, für ein Cookie wie promo_shown einschränken. Wenn Leser dem Link folgen auf der Website möchte er, dass das Cookie gesendet wird, damit seine Präferenz übernommen werden kann.

SameSite=Lax ermöglicht dem Browser, das Cookie mit diesen Navigation. Wenn beispielsweise eine andere Website auf den Inhalt Ihrer Website verweist, wird in Verwenden Sie für diesen Fall Ihr Katzenfoto und geben Sie einen Link zu Ihrem Artikel als folgt:

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

Mit einem Cookie, das so 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, Website sendet das Cookie nicht. Wenn die Lesenden jedoch cat.html auf Ihrer Website verlinkt, enthält diese Anfrage das Cookie.

Wir empfehlen, SameSite auf diese Weise zu verwenden und Cookies zu setzen, die sich auf die Website auswirken Anzeige für Lax und Cookies für Nutzeraktionen mit Strict.

Sie können SameSite auch auf None setzen, um anzugeben, dass das Cookie in allen Kontexten gesendet werden. Wenn Sie einen Dienst anbieten, den andere Websites wie Widgets, eingebettete Inhalte, Affiliate-Programme, Werbung oder Anmeldung in Websites vorhanden sind, solltest du None verwenden, damit deine Absicht klar erkennbar ist.

</ph> <ph type="x-smartling-placeholder">

Änderungen am Standardverhalten ohne SameSite

Das Attribut SameSite wird allgemein unterstützt, aber noch nicht weit verbreitet. Früher wurden Cookies ohne SameSite standardmäßig gesendet. Dadurch werden Nutzende anfällig für CSRF und unbeabsichtigte und Informationslecks. Um Entwickler zu ermutigen, ihre Absichten zu äußern und die Nutzung sicherer zu gestalten, den IETF-Vorschlag, Inkrementell bessere Cookies werden zwei wesentliche Änderungen erläutert:

• Cookies ohne SameSite-Attribut werden wie SameSite=Lax behandelt.
• Für Cookies mit SameSite=None muss auch der Parameter Secure angegeben werden. Das bedeutet, dass für sie Folgendes erforderlich ist: in einem sicheren Kontext.

Beide Änderungen sind abwärtskompatibel mit Browsern, die vorherige Version des Attributs SameSite implementiert haben und Browser, die ältere SameSite-Versionen nicht unterstützen. Sie sind dazu gedacht, die Entwickelnden weniger der Abhängigkeit von Browsern Standardverhalten festlegen, indem und die beabsichtigte Verwendung explizit ist. Alle Kunden, die die SameSite=None sollte sie ignorieren.

Standardmäßig SameSite=Lax

Wenn Sie ein Cookie senden, ohne sein SameSite-Attribut anzugeben, wird der Browser behandelt dieses Cookie so, als wäre es auf SameSite=Lax gesetzt. Wir empfehlen weiterhin, SameSite=Lax explizit festlegen, um die Nutzererfahrung zu vereinheitlichen in verschiedenen Browsern.

SameSite=None muss sicher sein

Wenn du websiteübergreifende Cookies mit SameSite=None erstellst, musst du sie auch setzen auf Secure, damit der Browser sie akzeptiert:

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

Ab Chrome 76 können Sie dieses Verhalten testen, indem Sie about://flags/#cookies-without-same-site-must-be-secure und von Firefox 69 indem Sie network.cookie.sameSite.noneRequiresSecure in about:config

Wir empfehlen außerdem, vorhandene Cookies so schnell wie möglich auf Secure zu aktualisieren. Wenn Sie Dienste nutzen, die Inhalte von Drittanbietern auf Ihrer Website anbieten, aktualisiert Ihr Internetanbieter seine Cookies sowie Snippets oder von Ihrer Website, um sicherzustellen, dass das neue Verhalten angewendet wird.

Rezepte für Kekse für SameSite

Weitere Informationen zur Aktualisierung Ihrer Cookies zur erfolgreichen Verarbeitung dieser Änderungen an SameSite=None und den Unterschieden beim Browserverhalten findest du in der Folgeartikel SameSite-Cookie-Rezepte.

Danke 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 am Unsplash