Chrome, Firefox, Edge und andere ändern ihr Standardverhalten gemäß dem IETF-Vorschlag Inkrementelle Better Cookies, sodass:
- Cookies ohne
SameSite
-Attribut werden wieSameSite=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.
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.](https://web.developers.google.cn/static/articles/samesite-cookie-recipes/image/diagram-a-browser-window-809ed902fbce7.png?authuser=6&hl=de)
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.](https://web.developers.google.cn/static/articles/samesite-cookie-recipes/image/diagram-a-request-moving-46b47373768e3.png?authuser=6&hl=de)
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:
- Melden Sie ein Problem im
SameSite
-Beispiel-Repository auf GitHub. - Stellen Sie eine Frage im "samesite"-Tag auf Stack Overflow.
- Wenn Sie Probleme mit dem Verhalten von Chromium haben, können Sie im Chromium Issue Tracker einen Fehler melden.
- Sie können den Fortschritt von Chrome auf der Seite mit den
SameSite
-Updates verfolgen.