SameSite-Cookie-Rezepte

Rowan Merewood

Chrome, Firefox, Edge und andere Browser ändern ihr Standardverhalten gemäß dem IETF-Vorschlag Incrementally Better Cookies, sodass Folgendes gilt:

• Cookies ohne ein SameSite-Attribut werden als SameSite=Lax behandelt, was bedeutet, dass das Standardverhalten darin besteht, Cookies auf Erstanbieterkontexte nur zu beschränken.
• Für die websiteübergreifende Verwendung von Cookies muss SameSite=None; Secure angegeben werden, damit sie in Drittanbieterkontexten verwendet werden können.

Wenn Sie das noch nicht getan haben, sollten Sie die Attribute für Ihre Drittanbieter-Cookies aktualisieren, damit sie in Zukunft nicht blockiert werden.

Anwendungsfälle für websiteübergreifende oder Drittanbieter-Cookies

Es gibt eine Reihe häufiger Anwendungsfälle und Muster, bei denen Cookies in einem Drittanbieterkontext gesendet werden müssen. Wenn Sie einen dieser Anwendungsfälle bereitstellen oder davon abhängig sind, müssen Sie oder der Anbieter die Cookies aktualisieren, damit der Dienst weiterhin ordnungsgemäß funktioniert.

Inhalte in einem <iframe>

Inhalte von einer anderen Website, die in einem <iframe> angezeigt werden, befinden sich in einem Drittanbieter kontext. Zu den Standardanwendungsfällen gehören:

• Eingebettete Inhalte, die von anderen Websites geteilt werden, z. B. Videos, Karten, Codebeispiele und Social-Media-Beiträge.
• Widgets von externen Diensten wie Zahlungen, Kalender, Buchungs- und Reservierungsfunktionen.
• Widgets wie Schaltflächen für soziale Netzwerke oder Dienste zum Schutz vor Betrug, die weniger offensichtliche <iframes> erstellen.

Cookies können hier unter anderem verwendet werden, um den Sitzungsstatus beizubehalten, allgemeine Einstellungen zu speichern, Statistiken zu aktivieren oder Inhalte für Nutzer mit bestehenden Konten zu personalisieren.

Da das Web von Natur aus zusammensetzbar ist, werden <iframes> auch verwendet, um Inhalte einzubetten, die in einem Kontext der obersten Ebene oder in einem Erstanbieterkontext angezeigt werden. Alle Cookies, die von der im iFrame angezeigten Website verwendet werden, gelten als Drittanbieter-Cookies. Wenn Sie Websites erstellen, die von anderen Websites eingebettet werden sollen, und Cookies benötigen, damit sie funktionieren, müssen Sie diese auch für die websiteübergreifende Verwendung kennzeichnen oder sicherstellen, dass Sie ohne sie problemlos auskommen.

„Unsichere“ Anfragen zwischen Websites

„Unsicher“ klingt hier vielleicht bedenklich, bezieht sich aber auf jede Anfrage, die den Status ändern könnte. Im Web sind das hauptsächlich POST-Anfragen. Cookies, die als SameSite=Lax gekennzeichnet sind, werden bei sicheren Navigationen der obersten Ebene gesendet, z. B. wenn ein Nutzer auf einen Link klickt, um zu einer anderen Website zu wechseln. Bei einer <form> Übermittlung an eine andere Website mit POST werden jedoch keine Cookies gesendet.

Dieses Muster wird für Websites verwendet, die den Nutzer zu einem Remote-Dienst umleiten können, um eine bestimmte Aktion auszuführen, bevor er zurückkehrt, z. B. die Umleitung zu einem Drittanbieter für die Identitätsbestätigung. Bevor der Nutzer die Website verlässt, wird ein Cookie mit einem Einmal-Token festgelegt. Es wird erwartet, dass dieses Token bei der Rückkehranfrage geprüft werden kann, um CSRF-Angriffe (Cross Site Request Forgery) zu verhindern. Wenn diese Rückkehranfrage per POST erfolgt, müssen Sie die Cookies als SameSite=None; Secure kennzeichnen.

Remote-Ressourcen

Jede Remote-Ressource auf einer Seite, z. B. aus <img>- oder <script>-Tags, erfordert möglicherweise, dass Cookies mit einer Anfrage gesendet werden. Häufige Anwendungsfälle sind Tracking-Pixel und die Personalisierung von Inhalten.

Das gilt auch für Anfragen, die von Ihrem JavaScript mit fetch oder XMLHttpRequest gesendet werden. Wenn fetch() mit der credentials: 'include' Option, diese Anfragen wahrscheinlich Cookies enthalten. Bei XMLHttpRequest werden erwartete Cookies in der Regel durch den withCredentials Wert fo true angegeben. Diese Cookies müssen entsprechend gekennzeichnet sein, damit sie in websiteübergreifenden Anfragen verwendet werden können.

Inhalte in einer WebView

Eine WebView in einer plattformspezifischen App wird von einem Browser unterstützt. Entwickler müssen testen, ob die Einschränkungen oder Probleme, die sich auf ihre Apps auswirken, auch für die WebViews ihrer App gelten.

Unter Android können plattformspezifische Apps auch Cookies direkt mit der CookieManager API festlegen. Wie bei Cookies, die mit Headern oder JavaScript festgelegt werden, sollten Sie SameSite=None; Secure verwenden, wenn sie für die websiteübergreifende Verwendung vorgesehen sind.

SameSite heute implementieren

Kennzeichnen Sie alle Cookies, die nur in einem Erstanbieterkontext benötigt werden, je nach Bedarf als SameSite=Lax oder SameSite=Strict. Wenn Sie diese Cookies nicht kennzeichnen und stattdessen auf das Standardverhalten des Browsers vertrauen, können sie sich in verschiedenen Browsern unterschiedlich verhalten und möglicherweise Konsolenwarnungen für jedes Cookie auslösen.

Set-Cookie: first_party_var=value; SameSite=Lax

Kennzeichnen Sie alle Cookies, die in einem Drittanbieterkontext benötigt werden, als SameSite=None; Secure. Beide Attribute sind erforderlich. Wenn Sie nur None ohne Secure angeben, wird das Cookie abgelehnt. Um Unterschiede bei der Browserimplementierung zu berücksichtigen, müssen Sie möglicherweise einige der Maßnahmen zur Risikominimierung verwenden, die unter Umgang mit inkompatiblen Clients beschrieben sind.

Set-Cookie: third_party_var=value; SameSite=None; Secure

Umgang mit inkompatiblen Clients

Da diese Änderungen, die None enthalten und das Standardverhalten aktualisieren, noch relativ neu sind, werden sie von verschiedenen Browsern unterschiedlich behandelt. Auf der Seite mit den Updates auf chromium.org finden Sie eine Liste bekannter Probleme. Diese Liste ist jedoch möglicherweise nicht vollständig.

Eine mögliche Problemumgehung besteht darin, jedes Cookie sowohl im neuen als auch im alten Stil festzulegen:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

Browser, die das neuere Verhalten implementieren, legen das Cookie mit dem SameSite-Wert fest. Browser, die das neue Verhalten nicht implementieren, ignorieren diesen Wert und legen das Cookie 3pcookie-legacy fest. Beim Verarbeiten der enthaltenen Cookies sollte Ihre Website zuerst prüfen, ob das Cookie im neuen Stil vorhanden ist, und dann auf das alte Cookie zurückgreifen, wenn kein neues gefunden wird.

Im folgenden Beispiel wird gezeigt, wie Sie das in Node.js mit dem Express-Framework und der Cookie-Parser Middleware tun:

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

Bei diesem Ansatz müssen Sie zusätzliche Arbeit leisten, indem Sie redundante Cookies festlegen und Änderungen sowohl beim Festlegen als auch beim Lesen des Cookies vornehmen. Er sollte jedoch alle Browser unabhängig von ihrem Verhalten abdecken und die Funktion von Drittanbieter-Cookies beibehalten.

Alternativ können Sie den Client mit dem User-Agent-String erkennen, wenn ein Set-Cookie-Header gesendet wird. Sehen Sie sich die Liste der inkompatiblen Clients an, und verwenden Sie eine geeignete Bibliothek zur Erkennung von User-Agents für Ihre Plattform, z. B. die ua-parser-js Bibliothek unter Node.js. Bei diesem Ansatz müssen Sie nur eine Änderung vornehmen, aber die Erkennung von User-Agents erfasst möglicherweise nicht alle betroffenen Nutzer.

Unterstützung für SameSite=None in Sprachen, Bibliotheken und Frameworks

Die meisten Sprachen und Bibliotheken unterstützen das SameSite-Attribut für Cookies. Da die Hinzufügung von SameSite=None jedoch noch relativ neu ist, müssen Sie vorerst möglicherweise einige Standardverhaltensweisen umgehen. Diese Verhaltensweisen sind im SameSite examples repository auf GitHub dokumentiert.

Hilfe erhalten

Cookies werden überall im Web verwendet und es kommt selten vor, dass ein Entwicklungsteam genau weiß, wo sie auf seiner Website festgelegt und verwendet werden, insbesondere in websiteübergreifenden Anwendungsfällen. Wenn Sie auf ein Problem stoßen, ist es möglicherweise das erste Mal, dass jemand darauf stößt. Zögern Sie also nicht, sich zu melden:

• Erstellen Sie ein Problem im SameSite examples repository auf GitHub.
• Stellen Sie eine Frage mit dem Tag „samesite“ auf StackOverflow.
• Bei Problemen mit dem Verhalten von Chromium können Sie einen Fehler im Chromium-Issue-Tracker melden.
• Auf der Seite mit den SameSite Updates können Sie den Fortschritt von Chrome verfolgen.