SameSite-Cookie-Rezepte

Rowan Merewood

Chrome, Firefox, Edge und andere ändern ihr Standardverhalten entsprechend dem IETF-Vorschlag Inkrementeller Bessere Cookies:

• 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 von gängigen Anwendungsfällen und Muster, bei denen Cookies im Zusammenhang mit Drittanbietern 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, z. B. 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 Dienste zur Betrugsbekämpfung, 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 vorhandenen 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 von anderen Websites eingebettet werden sollen, und Sie Cookies benötigen, damit sie funktionieren, müssen Sie auch darauf achten, dass diese für die websiteübergreifende Nutzung gekennzeichnet sind oder ohne dass Sie den Zugriff auf Cookies erlauben können.

„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. Bei 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 Android-Apps Cookies direkt über die CookieManager API 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 für eigene Zwecke benötigt werden, je nach Bedarf als SameSite=Lax oder SameSite=Strict. Wenn Sie diese Cookies nicht markieren und stattdessen das Standardverhalten des Browsers verwenden, können sie sich in den Browsern unterschiedlich verhalten und möglicherweise für jedes Cookie Warnungen in der Konsole auslösen.

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. Da Unterschiede in der Browserimplementierung berücksichtigt werden können, müssen Sie möglicherweise einige der Minderungsstrategien anwenden, die unter Umgang mit inkompatiblen Clients beschrieben werden.

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

Umgang mit inkompatiblen Clients

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

Eine Behelfslösung besteht darin, für jedes Cookie sowohl das neue als auch das alte Design 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. Allerdings sollten damit alle Browser unabhängig von ihrem Verhalten abgedeckt sein und Drittanbieter-Cookies weiter funktionieren.

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 Attribut SameSite 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-Beispiel-Repository 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 SameSite-Beispielsrepository 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.