SameSite-Cookie-Rezepte

Rowan Merewood

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

  • Cookies ohne SameSite-Attribut werden wie SameSite=Lax behandelt. Das bedeutet, dass Cookies nur auf Erstanbieterkontexte beschränkt sind.
  • In Cookies für die websiteübergreifende Nutzung muss SameSite=None; Secure angegeben werden, damit sie in den Kontext von Drittanbietern aufgenommen werden können.

Falls noch nicht geschehen, sollten Sie die Attribute für Ihre Drittanbieter-Cookies aktualisieren, damit diese in Zukunft nicht blockiert werden.

Unterstützte Browser

  • 51
  • 16
  • 60
  • 13

Quelle

Anwendungsfälle für website- 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 auf einen dieser Anwendungsfälle angewiesen sind, müssen Sie oder der Anbieter seine Cookies aktualisieren, damit der Dienst ordnungsgemäß funktioniert.

Inhalte in einem <iframe>

Inhalte einer anderen Website, die in einem <iframe> angezeigt werden, stammen aus dem Kontext eines Drittanbieters. Zu den Standardanwendungsfällen gehören:

  • Eingebettete Inhalte, die von anderen Websites geteilt wurden, z. B. Videos, Karten, Codebeispiele und Beiträge in sozialen Netzwerken
  • Widgets von externen Diensten wie Zahlungen, Kalender, Buchungs- und Reservierungsfunktionen.
  • Widgets wie Schaltflächen für soziale Netzwerke oder Dienste zur Betrugsbekämpfung, die weniger offensichtliche <iframes>.

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.

Diagramm eines Browserfensters, in dem die URL der eingebetteten Inhalte nicht mit der URL der Seite übereinstimmt.
Wenn die eingebetteten Inhalte nicht von derselben Website wie der Browserkontext auf oberster Ebene stammen, handelt es sich um Inhalte von Drittanbietern.

Da das Web von Natur aus zusammensetzbar ist, werden <iframes> auch verwendet, um Inhalte einzubetten, die in einem Erstanbieterkontext angesehen werden. Alle Cookies, die von der Website im iFrame verwendet werden, werden als Drittanbieter-Cookies betrachtet. Wenn Sie Websites erstellen, die in andere Websites eingebettet werden sollen, und Cookies benötigen, damit sie funktionieren, müssen Sie auch darauf achten, dass diese für die websiteübergreifende Nutzung gekennzeichnet sind oder dass Sie problemlos auf sie zurückgreifen können.

„Unsichere“ Anfragen auf mehreren Websites

„Unsicher“ klingt hier besorgniserregend, bezieht sich jedoch auf jede Anfrage, mit der der Status geändert werden kann. Im Web sind das in erster Linie POST-Anfragen. Als SameSite=Lax gekennzeichnete Cookies werden in sicheren Navigationen auf oberster Ebene gesendet, z. B. wenn auf einen Link geklickt wird, um zu einer anderen Website zu gelangen. Ein <form>-Eintrag an eine andere Website, der POST verwendet, enthält jedoch keine Cookies.

Diagramm einer Anfrage, die von einer Seite zu einer anderen wechselt.
Wenn bei der eingehenden Anfrage eine „sichere“ Methode verwendet wird, sendet die Seite Cookies.

Dieses Muster wird für Websites verwendet, die den Nutzer zu einem Remote-Dienst weiterleiten können, um vor der Rückgabe einen Vorgang auszuführen, z. B. eine Weiterleitung an einen externen Identitätsanbieter. Bevor der Nutzer die Website verlässt, wird ein Cookie mit einem Einmalnutzungstoken festgelegt. Es wird erwartet, dass dieses Token bei der zurückgegebenen Anfrage überprüft werden kann, um Angriffe auf Cross-Site Request Forgery (CSRF) abzuschwächen. Wenn die zurückgegebene Anfrage über POST erfolgt, müssen Sie die Cookies als SameSite=None; Secure markieren.

Remote-Ressourcen

Jede Remote-Ressource auf einer Seite, z. B. über <img>- oder <script>-Tags, kann auf Cookies basieren, die mit einer Anfrage gesendet werden. Gängige Anwendungsfälle sind beispielsweise das Tracking von Pixeln und die Personalisierung von Inhalten.

Dies gilt auch für Anfragen, die von deinem 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 werden, damit sie in websiteübergreifenden Anfragen verwendet werden können.

Inhalt in einem WebView

Ein WebView in einer plattformspezifischen App wird durch einen 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.

Android ermöglicht seinen plattformspezifischen Apps außerdem die Möglichkeit, Cookies direkt mithilfe der CookieManager API zu setzen. Wie bei Cookies, die mithilfe von Headern oder JavaScript gesetzt werden, solltest du SameSite=None; Secure einfügen, wenn sie für die websiteübergreifende Verwendung bestimmt sind.

SameSite jetzt implementieren

Markieren Sie alle Cookies, die nur in selbst erhobenen Daten benötigt werden, je nach Ihren Anforderungen mit SameSite=Lax oder SameSite=Strict. Wenn Sie diese Cookies nicht markieren und stattdessen auf das Standardverhalten des Browsers angewiesen sind, um sie zu verarbeiten, können sie in verschiedenen Browsern unterschiedlich verhalten und möglicherweise für jedes Cookie Konsolenwarnungen 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 Browserimplementierungen zu berücksichtigen, müssen Sie möglicherweise einige der Strategien zur Risikominderung 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, die None enthalten und das Standardverhalten für Updates enthalten sind, noch relativ neu sind, werden sie von verschiedenen Browsern unterschiedlich verarbeitet. Eine Liste mit bekannten Problemen findest du auf der Updates-Seite unter chromium.org. Diese Liste ist aber unter Umständen nicht vollständig.

Sie können das Problem umgehen, indem Sie jedes Cookie sowohl im neuen als auch im alten Stil setzen:

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

Browser, die das neuere Verhalten implementieren, setzen das Cookie mit dem Wert SameSite. Browser, in denen das neue Verhalten nicht implementiert ist, ignorieren diesen Wert und setzen das Cookie 3pcookie-legacy. Bei der Verarbeitung eingeschlossener Cookies sollte Ihre Website zuerst prüfen, ob der neue Cookie-Stil vorhanden ist, und dann auf das alte Cookie zurückgreifen, wenn es kein neues finden kann.

Das folgende Beispiel zeigt, wie dies in Node.js mit dem Express-Framework und seiner 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 Arbeitsschritte ausführen, um redundante Cookies zu setzen und Änderungen sowohl beim Setzen als auch beim Lesen des Cookies vorzunehmen. Sie sollte jedoch alle Browser unabhängig von ihrem Verhalten abdecken und Drittanbieter-Cookies weiterhin funktionieren.

Alternativ kannst du den Client mithilfe 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 User-Agent-Erkennungsbibliothek für Ihre Plattform, z. B. die ua-parser-js-Bibliothek auf Node.js. Bei diesem Ansatz müssen Sie nur eine Änderung vornehmen, aber das User-Agent-Sniffing erkennt 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 Attribut SameSite für Cookies. Da das Hinzufügen von SameSite=None jedoch noch relativ aktuell ist, müssen Sie vorerst ein Standardverhalten umgehen. Diese Verhaltensweisen sind im SameSite-Beispiel-Repository auf GitHub dokumentiert.

Unterstützung erhalten

Cookies werden überall im Web verwendet. Vor allem bei websiteübergreifenden Anwendungsfällen haben Entwicklungsteams nur selten vollständige Kenntnisse darüber, wo ihre Website sie festlegt und verwendet. Wenn ein Problem auftritt, ist es vielleicht das erste Mal, dass jemand darauf gestoßen ist. Zögern Sie also nicht, sich an uns zu wenden: