Die Definition von „same-site“ umfasst nun auch das URL-Schema, sodass Links zwischen HTTP- und HTTPS-Versionen einer Website jetzt als websiteübergreifende Anfragen gezählt werden. Führen Sie standardmäßig ein Upgrade auf HTTPS durch, um Probleme zu vermeiden, oder lesen Sie weiter, um zu erfahren, welche SameSite-Attributwerte erforderlich sind.
Schemeful Same-Site ändert die Definition einer (Website) von der registrierbaren Domain in die Schema- und registrierbare Domain. Weitere Details und Beispiele finden Sie unter Informationen zu „same-site“ und „same-origin“.
Die gute Nachricht ist: Wenn Ihre Website bereits vollständig auf HTTPS umgestellt ist, müssen Sie sich um nichts kümmern. Für Sie ändert sich nichts.
Falls Sie Ihre Website noch nicht vollständig umgestellt haben, sollte dies die höchste Priorität haben.
Falls Besucher Ihrer Website jedoch zwischen HTTP und HTTPS wechseln, finden Sie nachfolgend einige dieser häufigen Szenarien und das damit verbundene Verhalten des SameSite
-Cookies.
Du kannst diese Änderungen sowohl für Tests in Chrome als auch in Firefox aktivieren.
- Aktivieren Sie in Chrome 86
about://flags/#schemeful-same-site
. Sie können den Fortschritt auf der Chrome-Statusseite verfolgen. - Legen Sie in Firefox 79 über
about:config
network.cookie.sameSite.schemeful
auftrue
fest. Verfolge den Fortschritt über das Bugzilla-Problem.
Einer der Hauptgründe für die Änderung von SameSite=Lax
als Standardwert für Cookies war der Schutz vor Cross-Site Request Forgery (CSRF). Unsicherer HTTP-Traffic bietet jedoch Netzwerkangreifern dennoch die Möglichkeit, Cookies zu manipulieren, die dann auf der sicheren HTTPS-Version der Website verwendet werden. Durch die Erstellung dieser zusätzlichen websiteübergreifenden Grenze zwischen Schemas sind Sie noch besser vor diesen Angriffen geschützt.
Häufige Szenarien für mehrere Schemata
Navigation
Beim Wechseln zwischen schemaübergreifenden Versionen einer Website (z. B. Verknüpfung von http://website.beispiel zu https://website.beispiel) konnten bisher SameSite=Strict
-Cookies gesendet werden. Dies wird jetzt als websiteübergreifende Navigation behandelt, was bedeutet, dass SameSite=Strict
-Cookies blockiert werden.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Blockiert | ⛔ Blockiert |
SameSite=Lax
|
✓ Zulässig | ✓ Zulässig |
SameSite=None;Secure
|
✓ Zulässig | ⛔ Blockiert |
Unterressourcen werden geladen
Alle Änderungen, die Sie hier vornehmen, gelten nur als vorübergehende Korrektur, während Sie das Upgrade auf die vollständige HTTPS-Version durchführen.
Beispiele für Unterressourcen sind Bilder, iFrames und Netzwerkanfragen mit XHR oder Fetch.
Durch das Laden einer schemaübergreifenden Unterressource auf einer Seite konnten bisher SameSite=Strict
- oder SameSite=Lax
-Cookies gesendet oder festgelegt werden. Jetzt wird dies wie alle anderen Drittanbieter- oder websiteübergreifenden Unterressourcen behandelt. Das bedeutet, dass alle SameSite=Strict
- oder SameSite=Lax
-Cookies blockiert werden.
Selbst wenn der Browser das Laden von Ressourcen unsicherer Schemas auf einer sicheren Seite zulässt, werden alle Cookies bei diesen Anfragen blockiert, da für Drittanbieter- oder websiteübergreifende Cookies Secure
erforderlich ist.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Blockiert | ⛔ Blockiert |
SameSite=Lax
|
⛔ Blockiert | ⛔ Blockiert |
SameSite=None;Secure
|
✓ Zulässig | ⛔ Blockiert |
Formulare posten
Beim Posten zwischen schemaübergreifenden Versionen einer Website konnten bisher mit SameSite=Lax
oder SameSite=Strict
festgelegte Cookies gesendet werden. Jetzt wird dies als websiteübergreifende POST-Anfrage behandelt – es können nur SameSite=None
-Cookies gesendet werden. Dieses Szenario kann auf Websites auftreten, auf denen standardmäßig die unsichere Version verwendet wird. Nutzer werden jedoch beim Senden des Anmelde- oder Check-out-Formulars auf die sichere Version aktualisiert.
Wie bei Unterressourcen werden alle Cookies bei diesen Anfragen blockiert, wenn die Anfrage von einem sicheren Kontext (z.B. HTTPS) an einen unsicheren Kontext (z.B. HTTP) weitergeleitet wird, da für Drittanbieter- oder websiteübergreifende Cookies Secure
erforderlich ist.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Blockiert | ⛔ Blockiert |
SameSite=Lax
|
⛔ Blockiert | ⛔ Blockiert |
SameSite=None;Secure
|
✓ Zulässig | ⛔ Blockiert |
Wie kann ich meine Website testen?
Tools und Mitteilungen für Entwickler sind in Chrome und Firefox verfügbar.
Ab Chrome 86 enthält der Tab „Problem“ in den Entwicklertools Informationen zu Schemeful Same-Site-Problemen. Für Ihre Website werden möglicherweise die folgenden Probleme hervorgehoben.
Probleme mit der Navigation:
- „Migrieren Sie vollständig zu HTTPS, damit weiterhin Cookies bei Anfragen derselben Website gesendet werden“: Es wird eine Warnung angezeigt, dass das Cookie in einer zukünftigen Version von Chrome blockiert wird.
- „Migration vollständig zu HTTPS, damit Cookies bei Anfragen von derselben Website gesendet werden“: Eine Warnung, dass das Cookie blockiert wurde.
Probleme beim Laden von Unterressourcen:
- „Migrieren Sie vollständig zu HTTPS, damit Cookies weiterhin an Unterressourcen derselben Website gesendet werden“ oder „Migrieren Sie vollständig zu HTTPS, um weiterhin Cookies durch Unterressourcen derselben Website zu setzen“: Warnungen, dass das Cookie in einer zukünftigen Version von Chrome blockiert wird.
- „Migration vollständig zu HTTPS, damit Cookies an Unterressourcen derselben Website gesendet werden“ oder „Migrieren Sie vollständig zu HTTPS, damit Cookies von Unterressourcen derselben Website gesetzt werden können“ – Warnungen, dass das Cookie blockiert wurde. Die zweite Warnung kann auch beim Senden eines Formulars angezeigt werden.
Weitere Informationen finden Sie unter Test- und Debugging-Tipps für Schemeful Same-Site.
In Firefox 79 und network.cookie.sameSite.schemeful
über about:config
auf true
gesetzt ist, zeigt die Konsole eine Meldung für Schemeful Same-Site-Probleme an.
Auf Ihrer Website kann Folgendes angezeigt werden:
- „Das Cookie
cookie_name
wird bald als websiteübergreifendes Cookie fürhttp://site.example/
behandelt, da das Schema nicht übereinstimmt.“ - „Das Cookie
cookie_name
wurde in Bezug aufhttp://site.example/
als websiteübergreifend behandelt, da das Schema nicht übereinstimmt.“
Häufig gestellte Fragen
Meine Website ist bereits vollständig über HTTPS verfügbar. Warum werden Probleme in den Entwicklertools meines Browsers angezeigt?
Es ist möglich, dass einige Ihrer Links und Unterressourcen immer noch auf unsichere URLs verweisen.
Eine Möglichkeit, dieses Problem zu beheben, besteht in der Verwendung von HTTP Strict-Transport-Security (HSTS) und der Anweisung includeSubDomain
. Mit HSTS und includeSubDomain
verwendet der Browser automatisch stattdessen die sichere Version, auch wenn eine Ihrer Seiten versehentlich einen unsicheren Link enthält.
Was passiert, wenn ich kein Upgrade auf HTTPS durchführen kann?
Zum Schutz Ihrer Nutzer empfehlen wir Ihnen dringend, Ihre Website vollständig auf HTTPS umzustellen. Falls Sie das nicht selbst tun können, sollten Sie sich an Ihren Hostanbieter wenden. Wenn Sie ein Zertifikat selbst hosten, bietet Let's Encrypt eine Reihe von Tools zum Installieren und Konfigurieren eines Zertifikats. Sie können Ihre Website auch hinter ein CDN oder einen anderen Proxy verlegen, der die HTTPS-Verbindung bereitstellen kann.
Wenn das immer noch nicht möglich ist, versuchen Sie, den SameSite
-Schutz für die betroffenen Cookies zu lockern.
- Wenn nur
SameSite=Strict
-Cookies blockiert werden, können Sie den Schutz aufLax
senken. - Wenn sowohl
Strict
- als auchLax
-Cookies blockiert werden und Ihre Cookies an eine sichere URL gesendet oder von einer sicheren URL gesetzt werden, können Sie den Schutz aufNone
senken.- Diese Problemumgehung schlägt fehl, wenn die URL, an die Sie Cookies senden oder von der Sie Cookies setzen, nicht sicher ist. Das liegt daran, dass
SameSite=None
das AttributSecure
für Cookies erfordert. Diese Cookies werden also möglicherweise nicht über eine unsichere Verbindung gesendet oder gesetzt. In diesem Fall können Sie erst auf dieses Cookie zugreifen, wenn Ihre Website auf HTTPS aktualisiert wurde. - Denken Sie daran, dass dies nur vorübergehend ist, da Drittanbieter-Cookies schließlich ganz eingestellt werden.
- Diese Problemumgehung schlägt fehl, wenn die URL, an die Sie Cookies senden oder von der Sie Cookies setzen, nicht sicher ist. Das liegt daran, dass
Wie wirkt sich das auf meine Cookies aus, wenn ich kein SameSite
-Attribut angegeben habe?
Cookies ohne SameSite
-Attribut werden so behandelt, als hätten sie SameSite=Lax
angegeben. Das gleiche Verhalten gilt auch für diese Cookies. Hinweis: Die vorübergehende Ausnahme von unsicheren Methoden gilt weiterhin. Weitere Informationen zur Abwehr von Lax- und POST-Anfragen in den SameSite
-FAQs von Chromium
Wie sind WebSockets betroffen?
WebSocket-Verbindungen gelten weiterhin als von derselben Website aus, wenn sie die gleiche Sicherheit wie die Seite haben.
Gleiche Website:
wss://
Verbindung vonhttps://
ws://
Verbindung vonhttp://
Websiteübergreifend:
wss://
Verbindung vonhttp://
ws://
Verbindung vonhttps://
Foto von Julissa Capdevilla auf Unsplash