Was bei SameSite Lax vs Strict vs None wirklich bricht

Was ist der Unterschied zwischen SameSite Lax vs Strict vs None?

Browser lesen SameSite Lax vs Strict vs None als drei Antworten auf eine einzige Frage: Welche seitenübergreifenden Anfragen dürfen dieses Cookie mitführen. RFC 6265bis nennt alle drei in einem einzigen Absatz von Abschnitt 4.1.2.7: "If the 'SameSite' attribute's value is 'Strict', the cookie will only be sent along with 'same-site' requests. If the value is 'Lax', the cookie will be sent with same-site requests, and with 'cross-site' top-level navigations, as described in Section 5.6.7.1. If the value is 'None', the cookie will be sent with same-site and cross-site requests."

Der geltende Entwurf ist draft-ietf-httpbis-rfc6265bis-22 vom 1. Dezember 2025, herausgegeben von Bingler, West und Wilander und markiert mit "Obsoletes: 6265 (if approved)". Das Attribut begrenzt die Reichweite nach Site statt nach Origin, https://www.site.example und https://api.site.example sind also dieselbe Site, und ob zwei Hosts dieselbe Site teilen, entscheidet die Public Suffix List statt der registrierbaren Domain allein.

Was erlaubt Lax, was Strict nicht erlaubt?

Lax erlaubt genau eine zusätzliche Klasse von Anfragen: eine seitenübergreifende Top-Level-Navigation mit einer sicheren HTTP-Methode. Der RFC nennt die Ausnahme und ihren Zweck in einem Zug und beschreibt Lax als "a drop-in mechanism that mitigates the risk of CSRF attacks", das "sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a 'safe' (in the [HTTP] sense) HTTP method."

MDN macht daraus den Test, den Sie in der Praxis anwenden. Eine Top-Level-Navigation "essentially means that the request causes the URL shown in the browser's address bar to change", was einen geklickten Link, eine Zuweisung an document.location und ein <form>-Submit einschließt und "requests made using the fetch() API, or requests for subresources from <img> or <script> elements, or navigations inside <iframe> elements" ausschließt. Die Hälfte mit der sicheren Methode "excludes POST, PUT, and DELETE."

Der RFC ist ehrlich darüber, was Lax Ihnen nicht einbringt. "Lax enforcement provides reasonable defense in depth against CSRF attacks that rely on unsafe HTTP methods (like POST), but does not offer a robust defense against CSRF as a general category of attack", denn "Attackers can still pop up new windows or trigger top-level navigations in order to create a 'same-site' request".

Was ist Chromes dokumentierter Standard für SameSite?

Chrome behandelt ein Cookie ohne SameSite-Attribut als Lax und dokumentiert eine bewusste Ausnahme. Googles eigene Referenz nennt die Regel: "If you send a cookie without specifying its SameSite attribute, the browser treats that cookie as if it were set to SameSite=Lax." Dieselbe Seite ergänzt die Ausnahme in einem Warnkasten: "Chrome's default behavior is slightly more permissive than an explicit SameSite=Lax, because it lets sites send some cookies on top-level POST requests. For details, see the blink-dev announcement. This is intended as a temporary mitigation."

Diese Seite trägt als Datum der letzten Aktualisierung den 7. Mai 2019 und eine Browser-Support-Tabelle, die für die Standardänderung Chrome 80 und Edge 86 nennt, Firefox hinter einem Flag und Safari als nicht unterstützt. Die IETF hat die Ausnahme, die Chrome temporär nennt, inzwischen formalisiert. RFC 6265bis nennt sie "Lax-allowing-unsafe" und legt fest, User Agents "MAY apply 'Lax-allowing-unsafe' enforcement only to cookies that did not explicitly specify a SameSite attribute", sie "SHOULD restrict the enforcement to cookies which were created recently", und "Deployment experience has shown a cookie age of 2 minutes or less to be a reasonable limit." MDN nennt dieselbe Zahl von der Browserseite: Unter einem per Standard gesetzten Lax gilt "cookies are also included in POST requests, as long as they were set no more than two minutes before the request was made."

Daraus folgen zwei Konsequenzen, und beide überraschen. SameSite=Lax explizit zu schreiben ist strenger, als nichts zu schreiben, weil der RFC Lax-allowing-unsafe nur auf Cookies anwendet, deren Flag durch Abwesenheit auf "Default" gesetzt wurde. Und "Lax-allowing-unsafe is not a distinct value of the SameSite attribute", es gibt also keine Zeichenkette, mit der Sie es anfordern könnten.

Die Spezifikation behandelt einen Tippfehler auf dieselbe Weise. "If the 'SameSite' attribute's value is something other than these three known keywords, the attribute's value will be subject to a default enforcement mode that is equivalent to 'Lax'." Ein Cookie mit SameSite=Laxx wird nicht abgelehnt, es gilt stillschweigend als nicht gesetzt.

Warum muss SameSite=None Secure tragen?

Ein Cookie, das SameSite=None ohne Secure behauptet, wird weggeworfen, und der RFC schreibt das in den Speicheralgorithmus statt in einen Ratschlag. Schritt 19 von Abschnitt 5.7 lautet: "If the cookie's 'same-site-flag' is 'None', abort this algorithm and ignore the cookie entirely unless the cookie's secure-only-flag is true."

Googles Referenz sagt Entwicklern dasselbe, "When you create cross-site cookies using SameSite=None, you must also set them to Secure for the browser to accept them", und liefert den vollständigen Header:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

MDNs Formulierung ist ebenso knapp: Für None gilt "The Secure attribute must also be set when using this value." Im Konsolenverlauf steht keine Warnung, die für die meisten Leute wie eine Warnung aussieht, weil das Cookie schlicht nie gespeichert wird. Wenn eine seitenübergreifende Integration auf Ihrem Rechner funktioniert und in der Produktion versagt, prüfen Sie zuerst, ob die Antwort SameSite=None über einfaches HTTP gesetzt hat.

Partitioned legt sich darüber, nicht an dessen Stelle. Browser akzeptieren dieses Attribut nur zusammen mit SameSite=None, was partitionierte CHIPS-Cookies geben jeder Site ihr eigenes Glas behandelt.

Was bricht in welchem Modus?

Der RFC illustriert das Scheitern von Strict mit einem Szenario statt mit einer Regel. Ein Nutzer liest Mail auf https://site.example und klickt einen Link zu https://projects.example/secret/project: "if https://projects.example has marked their session cookies as SameSite=Strict, then this cross-site navigation won't send them along with the request. https://projects.example will render a 404 error to avoid leaking secret information, and the user will be quite confused." Strict lässt jeden eingehenden Link aus Suche, Mail, Chat und Social beim ersten Rendern wie einen ausgeloggten Besuch aussehen.

Der vorgeschriebene Ausweg sind zwei Cookies statt eines, "one conceptually granting 'read' access, another granting 'write' access. The latter could be marked as SameSite=Strict, and its absence would prompt a reauthentication step before executing any non-idempotent action. The former could be marked as SameSite=Lax."

Lax bricht eine engere Menge an Dingen, und der RFC benennt den schärfsten Fall: "the concluding step of a login flow may involve a cross-site top-level POST request to an endpoint; this endpoint expects a recently created cookie containing transactional state information, necessary to securely complete the login." Unter explizitem Lax fällt dieses Cookie aus Methodengründen heraus, "resulting in an unrecoverable failure of the whole login flow." Single Sign-on und Rücksprünge aus Zahlungen scheitern auf dieselbe Weise.

None bricht per Regel nichts und per Richtlinie alles. Der RFC benennt die Fälle, die es brauchen, "content intended for embedding in cross-site contexts (social networking widgets or commenting services, for instance) will not have access to same-site cookies. Cookies which are required in these situations should be marked with SameSite=None", und ergänzt, dass "some forms of Single-Sign-On might require cookie-based authentication in a cross-site context". Ein SameSite=None; Secure-Cookie ist in jedem Sinn, der für die Datenschutzkontrollen eines Browsers zählt, ein Third-Party Cookie und erbt damit jede Einschränkung, die diese Kontrollen verhängen. Diese Erbschaft ist die ganze Geschichte in nur die Domain entscheidet über First-Party vs Third-Party Cookies und in was das 7-Tage-Cookie-Limit von Safari tatsächlich einschränkt.

Kann eine seitenübergreifende Antwort ein Lax- oder Strict-Cookie setzen?

Nein, und diese Regel ist von der Auslieferung getrennt. Abschnitt 4.1.2.7 stellt fest: "The 'SameSite' attribute affects cookie creation as well as delivery. Cookies which assert 'SameSite=Lax' or 'SameSite=Strict' cannot be set in responses to cross-site subresource requests, or cross-site nested navigations. They can be set along with any top-level navigation, cross-site or otherwise."

Ein eingebettetes Widget, das in einem <iframe> auf der Seite eines anderen lädt, kann also überhaupt kein Lax-Cookie schreiben, was immer es vorhaben mag. Das einzige Cookie, das es schreiben kann, ist SameSite=None; Secure. Analyse-Skripte von einer gemeinsam genutzten Anbieterdomain laufen ständig dagegen, und das ist einer der Gründe, warum First-Party-Skripthosting und die Link-Dekoration, auf die Apple zielt, ins Zentrum des Messdesigns gerückt sind.

Häufig gestellte Fragen

Welchen SameSite-Wert sollte ein Session-Cookie verwenden?

Lax für ein Session-Cookie, das einen eingehenden Link überleben muss, denn der RFC nennt Lax einen "drop-in mechanism that mitigates the risk of CSRF attacks". Strict für alles, was eine zustandsändernde Aktion absichert, nach dem Zwei-Cookie-Muster des RFC, in dem für die Strict-Hälfte gilt, ihre "absence would prompt a reauthentication step before executing any non-idempotent action."

Ist das Weglassen von SameSite dasselbe wie SameSite=Lax?

In Chrome nicht. Google dokumentiert den Standard als permissiver, er "lets sites send some cookies on top-level POST requests." RFC 6265bis begrenzt dieses Lax-allowing-unsafe-Verhalten auf "cookies that did not explicitly specify a SameSite attribute", mit einer empfohlenen Altersgrenze von "2 minutes or less". Das Attribut auszuschreiben liefert Ihnen strengeres Verhalten, als es wegzulassen.

Erfordert SameSite=None HTTPS?

Ja, indirekt, weil es Secure erfordert und Secure-Cookies auf sichere Protokolle beschränkt sind. RFC 6265bis verwirft das Cookie in Schritt 19 rundheraus, ignorieren Sie es "unless the cookie's secure-only-flag is true."

Stoppt SameSite CSRF im Alleingang?

Nein. Der RFC sagt, Lax "does not offer a robust defense against CSRF as a general category of attack", und verweist Entwickler darauf, "more completely mitigate CSRF through a session management mechanism". Googles Leitfaden ergänzt: "Neither Strict nor Lax is a complete solution for your site's security."

Was passiert, wenn ich einen ungültigen SameSite-Wert sende?

Er wird behandelt, als hätten Sie nichts gesendet. Nach Abschnitt 4.1.2.7 bekommt ein Wert "other than these three known keywords" "a default enforcement mode that is equivalent to 'Lax'", und der Speicheralgorithmus setzt das same-site-flag des Cookies auf "Default". Groß- und Kleinschreibung spielt keine Rolle, da der RFC "None", "Strict" und "Lax" ohne Rücksicht darauf abgleicht.

Entscheidet bei SameSite die Domain oder die Site?

Die Site, die breiter als eine Origin und enger als eine Domain ist. Subdomains einer registrierbaren Site sind untereinander same-site, und Googles Referenz zeigt auf die Grenze, über die viele stolpern: Die Public Suffix List "doesn't just depend on top-level domains like .com, but can also include services like github.io", also sind your-project.github.io und my-project.github.io getrennte Sites.

Warum brechen Links aus E-Mails oder Suchergebnissen bei SameSite=Strict?

Die RFC beschreibt genau diesen Fall: Ein Nutzer liest eine E-Mail, klickt auf einen Link zu einer Seite mit SameSite=Strict-Session-Cookies, und die seitenübergreifende Navigation sendet diese Cookies nicht mit. Die Zielseite zeigt einen 404-Fehler, um keine Daten preiszugeben, und der Nutzer sieht beim ersten Laden eine scheinbar abgemeldete Seite. Die von der RFC vorgeschlagene Lösung sind zwei Cookies statt eines, wobei nur das Schreib-Cookie als Strict markiert wird und das Lese-Cookie als Lax.

Warum scheitert ein Login-Ablauf bei SameSite=Lax?

Manche Login-Abläufe enden mit einem seitenübergreifenden Top-Level-POST an einen Callback-Endpunkt, der ein kürzlich erstelltes Cookie mit Transaktionsdaten erwartet. Ein explizit gesetztes SameSite=Lax-Cookie wird bei dieser Anfrage ausgeschlossen, weil POST keine sichere Methode ist, was die RFC als "unrecoverable failure of the whole login flow" beschreibt. Single Sign-On und Rückkehr-Hops bei Zahlungen scheitern aus demselben Grund.

Kann ein seitenübergreifendes iFrame-Widget ein Lax-Cookie setzen?

Nein. Abschnitt 4.1.2.7 legt fest, dass Cookies mit SameSite=Lax oder SameSite=Strict nicht in Antworten auf seitenübergreifende Subresource-Anfragen oder seitenübergreifende verschachtelte Navigationen gesetzt werden können, was ein in einer fremden Seite eingebettetes iFrame einschließt. Das einzige Cookie, das ein solches Widget setzen kann, ist SameSite=None mit Secure.

Was hat das Partitioned-Attribut mit SameSite=None zu tun?

Partitioned setzt auf SameSite=None auf, statt es zu ersetzen. Browser akzeptieren das Partitioned-Attribut nur zusammen mit SameSite=None, was CHIPS erlaubt, jeder Seite ihr eigenes Cookie-Glas zu geben, während die Anforderungen von None und Secure bestehen bleiben.