SameSite-Cookie-Rezepte

Rowan Merewood

Chrome, Firefox, Edge und andere ändern ihr Standardverhalten gemäß dem IETF-Vorschlag Incrementally Better Cookies (schrittweise bessere Cookies). Das hat folgende Auswirkungen:

• Cookies ohne SameSite-Attribut werden als SameSite=Lax behandelt. Das bedeutet, dass Cookies standardmäßig nur auf Kontexte mit selbst erhobenen Daten beschränkt werden.
• Für websiteübergreifende Cookies muss SameSite=None; Secure angegeben werden, damit sie im Kontext von Drittanbietern verwendet werden können.

Aktualisieren Sie die Attribute für Drittanbieter-Cookies, falls Sie dies noch nicht getan haben, damit sie in Zukunft nicht mehr blockiert werden.

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

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

Inhalte in einem <iframe>

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

• Von anderen Websites eingebettete Inhalte wie Videos, Karten, Codebeispiele und Beiträge in sozialen Medien
• Widgets von externen Diensten wie Zahlungs-, Kalender-, Buchungs- und Reservierungsfunktionen
• Widgets wie Schaltflächen für soziale Netzwerke oder Anti-Betrugsdienste, die weniger offensichtliche <iframes>erstellen.

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

Da das Web von Natur aus kombinierbar ist, werden <iframes> auch zum Einbetten von Inhalten verwendet, die in einem Top-Level- oder selbst erhobenen Kontext angezeigt werden. Alle Cookies, die von der im Iframe angezeigten Website verwendet werden, gelten als Drittanbieter-Cookies. Wenn Sie Websites erstellen, die in andere Websites eingebettet werden sollen, und dafür Cookies benötigen, müssen Sie diese auch für die websiteübergreifende Verwendung kennzeichnen oder dafür sorgen, dass ein reibungsloser Übergang ohne sie möglich ist.

„Unsichere“ Anfragen zwischen Websites

„Unsicher“ mag hier besorgniserregend klingen, 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 Sie auf einen Link klicken, um eine andere Website aufzurufen. Eine POST-Einreichung von <form> an eine andere Website enthält jedoch keine Cookies.

Dieses Muster wird für Websites verwendet, die Nutzer zu einem Remote-Dienst weiterleiten können, um eine bestimmte Aktion auszuführen, bevor sie zurückgeleitet werden, z. B. zu einem Identitätsanbieter eines Drittanbieters. Bevor der Nutzer die Website verlässt, wird ein Cookie mit einem Einmaltoken gesetzt. Dieses Token soll bei der Rückgabeanfrage überprüft werden, um Cross-Site Request Forgery (CSRF)-Angriffe zu verhindern. Wenn diese zurückgegebene Anfrage über POST erfolgt, müssen Sie die Cookies als SameSite=None; Secure kennzeichnen.

Remote-Ressourcen

Für jede Remoteressource auf einer Seite, z. B. von <img>- oder <script>-Tags, ist es möglich, dass Cookies mit einer Anfrage gesendet werden. Zu den häufigsten Anwendungsfällen gehören Tracking-Pixel und die Personalisierung von Inhalten.

Das gilt auch für Anfragen, die über JavaScript mit fetch oder XMLHttpRequest gesendet werden. Wenn fetch() mit der Option credentials: 'include' aufgerufen wird, enthalten diese Anfragen wahrscheinlich Cookies. Für XMLHttpRequest werden erwartete Cookies in der Regel durch einen withCredentials-Wert für true angegeben. Diese Cookies müssen entsprechend gekennzeichnet sein, damit sie in websiteübergreifende Anfragen einbezogen werden.

Inhalte in einem WebView

Ein 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 auf die WebViews ihrer App zutreffen.

Außerdem können Plattform-spezifische Apps von Android über die CookieManager API direkt Cookies setzen. Wie bei Cookies, die über Header oder JavaScript festgelegt werden, sollten Sie SameSite=None; Secure verwenden, wenn sie für die websiteübergreifende Verwendung vorgesehen sind.

SameSite heute implementieren

Markieren Sie alle Cookies, die nur in einem First-Party-Kontext erforderlich sind, je nach Bedarf als SameSite=Lax oder SameSite=Strict. Wenn Sie diese Cookies nicht kennzeichnen und stattdessen das Standardbrowserverhalten für die Verarbeitung verwenden, kann sich ihr Verhalten in verschiedenen Browsern unterscheiden und es können möglicherweise Konsolenwarnungen für jedes Cookie ausgelöst werden.

Set-Cookie: first_party_var=value; SameSite=Lax

Achten Sie darauf, alle Cookies, die in einem Drittanbieterkontext erforderlich sind, als SameSite=None; Secure zu kennzeichnen. Beide Attribute sind erforderlich. Wenn Sie nur None ohne Secure angeben, wird das Cookie abgelehnt. Um Unterschiede in der Browserimplementierung zu berücksichtigen, müssen Sie möglicherweise einige der in Inkompatible Clients verarbeiten beschriebenen Strategien zur Risikobewältigung anwenden.

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

Umgang mit inkompatiblen Clients

Da diese Änderungen zur Aufnahme von None und zum Aktualisieren des Standardverhaltens noch relativ neu sind, werden sie von verschiedenen Browsern unterschiedlich verarbeitet. Auf der Updateseite auf chromium.org finden Sie eine Liste bekannter Probleme. Diese Liste ist jedoch möglicherweise nicht vollständig.

Eine mögliche Lösung 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

In Browsern, die das neuere Verhalten implementieren, wird das Cookie mit dem SameSite-Wert festgelegt. In Browsern, die das neue Verhalten nicht implementieren, wird dieser Wert ignoriert und das 3pcookie-legacy-Cookie gesetzt. Bei der Verarbeitung von eingebundenen Cookies sollte Ihre Website zuerst prüfen, ob der neue Cookie-Typ vorhanden ist, und dann auf das alte Cookie zurückgreifen, wenn kein neuer gefunden wird.

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

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, um redundante Cookies festzulegen und Änderungen sowohl beim Festlegen als auch beim Lesen des Cookies vorzunehmen. Sie sollte jedoch alle Browser unabhängig von ihrem Verhalten abdecken und die Funktion von Drittanbieter-Cookies aufrechterhalten.

Alternativ kannst du den Client anhand des User-Agent-Strings erkennen, wenn ein Set-Cookie-Header gesendet wird. Sehen Sie sich die Liste der inkompatiblen Clients an und verwenden Sie eine geeignete Bibliothek zur User-Agent-Erkennung 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 das User-Agent-Sniffing erfasst möglicherweise nicht alle betroffenen Nutzer.

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

Die meisten Sprachen und Bibliotheken unterstützen das SameSite-Attribut für Cookies. Da SameSite=None jedoch erst vor Kurzem hinzugefügt wurde, müssen Sie einige Standardfunktionen möglicherweise vorerst umgehen. Diese Verhaltensweisen sind im SameSite-Beispielsrepository auf GitHub dokumentiert.

Hilfe erhalten

Cookies werden überall im Web verwendet und es ist selten, dass ein Entwicklerteam genau weiß, wo auf seiner Website sie gesetzt und verwendet werden, insbesondere bei websiteübergreifenden Anwendungsfällen. Wenn du ein Problem feststellst, ist es möglicherweise das erste Mal, dass es auftritt. Zögere nicht, dich an uns zu wenden:

• Melden Sie ein Problem im Beispiel-Repository für SameSite auf GitHub.
• Stellen Sie eine Frage unter dem Tag „samesite“ auf Stack Overflow.
• Wenn Sie Probleme mit dem Verhalten von Chromium haben, melden Sie einen Fehler im Chromium-Fehler-Tracker.
• Sie können den Fortschritt des Chrome-Updates auf der Seite SameSite „Updates“ verfolgen.