Was ist SameSite?
Du bist in deinem Shop eingeloggt und klickst auf einer anderen Website einen Link dorthin. Soll der Browser dein Login-Cookie mitschicken? Meist ja. Und wenn eine fremde Seite im Hintergrund ein Formular an deinen Shop schickt? Lieber nicht. Diese Entscheidung regelt SameSite.
SameSite ist ein Attribut, das eine Website beim Setzen eines Cookies mitgibt. Es legt fest, ob der Browser das Cookie auch bei Anfragen schickt, die von einer anderen Website ausgehen. Laut MDN gibt es drei Werte:
- Strict: Das Cookie geht nur mit, wenn die Anfrage von derselben Website kommt.
- Lax: Wie Strict, aber das Cookie geht auch mit, wenn jemand von außen per Link auf deine Seite wechselt. Bei Formularen von fremden Seiten bleibt es draußen.
- None: Das Cookie geht immer mit, auch von fremden Seiten. Dann muss es zusätzlich als Secure markiert sein, also nur über HTTPS laufen.
Was „gleiche Website“ bedeutet
Hier wird es kleinteilig, aber es ist wichtig. Eine Site besteht aus dem Protokoll und der registrierbaren Domain. Ein Origin ist genauer: Protokoll, kompletter Hostname und Port.
Vergleich
Gleiche Site?
www.beispiel.de ↔ shop.beispiel.de
Ja
beispiel.de ↔ anderer-shop.de
Nein
http:// ↔ https:// derselben Domain
Nein
Subdomains gelten also als dieselbe Site. Das ist praktisch für Shop und Blog auf verschiedenen Subdomains — aber auch eine Schwachstelle, wenn eine Subdomain in fremde Hände gerät.
Was Chrome 2020 geändert hat
Früher gingen Cookies ohne SameSite-Angabe überall mit. Mit Chrome 80 im Februar 2020 änderte Google das: Cookies ohne Angabe gelten als Lax, und None funktioniert nur noch mit Secure. Wegen der Pandemie setzte Google die Umstellung im April 2020 kurz aus und rollte sie ab Juli wieder aus. Im August 2020 galt sie für alle Nutzer.
Eine Ausnahme hat Chrome eingebaut: Cookies ohne Angabe gehen bei Formular-Sendungen von außen noch mit, wenn sie höchstens zwei Minuten alt sind. Das rettet manche Login-Abläufe.
Fall A · Onlineshop
Rücksprung von der Bank
POST
von fremder Website
weg
Sitzung und Warenkorb
Bei 3-D Secure schickt die Bank den Kunden per Formular zurück. Ist das Sitzungs-Cookie Lax, fehlt es dabei — der Kunde steht ohne Warenkorb da.
Im WordPress-Bugtracker dokumentiert. Lösung: Rücksprung per Link statt Formular oder das Cookie gezielt auf None mit Secure setzen.
Fall B · Eingebettetes Widget
Buchungstool im iframe
Lax
kommt nicht mit
None + Secure
nötig
Ein Widget auf einer fremden Website braucht seine eigenen Cookies. Mit Lax bleiben sie draußen, das Widget vergisst den Nutzer.
web.dev empfiehlt None ausdrücklich für Widgets, eingebettete Inhalte und Logins über mehrere Websites.
Häufige Fehler
Fehler 1 · None ohne Secure
SameSite=None ohne Secure nimmt der Browser gar nicht an. Das Cookie ist dann einfach weg, ohne Fehlermeldung auf der Seite.
Fehler 2 · Alles auf None stellen
„Damit es läuft“ wird jedes Cookie auf None gesetzt. Damit verschenkst du den Schutz, den SameSite bietet. Und in Safari funktioniert es trotzdem nicht, weil Cookies für fremde Websites dort blockiert sind.
Fehler 3 · SameSite als einzigen Schutz nehmen
Die Sicherheitsorganisation OWASP nennt SameSite eine zusätzliche Schutzschicht, keinen Ersatz für echten Schutz vor Cross-Site Request Forgery. Wer Änderungen per einfachem Link auslöst, ist auch mit Lax angreifbar.
Fehler 4 · Tracking-Probleme falsch zuordnen
Fehlen Conversions aus eingebetteten Formularen oder Bezahlschritten, liegt es oft nicht am Tag Manager, sondern am Cookie-Kontext. Prüf zuerst, ob das Cookie bei der Anfrage überhaupt mitging.
So prüfst du deine Cookies
- Chrome DevTools: Unter Application → Storage → Cookies zeigt die Spalte SameSite den Wert jedes Cookies. Ungültige Werte sind rot markiert, mit dem Filter für Cookies mit Problemen siehst du nur die kritischen.
- Network-Tab: Bei einer einzelnen Anfrage zeigt Chrome, welche Cookies blockiert wurden und warum.
- Bezahlvorgang testen: Einmal echt bis zum Rücksprung durchklicken, in Chrome und in Safari.
- Plugins und Dienste prüfen: Viele Cookies setzt nicht deine Website, sondern ein Plugin. Dort gehört die Einstellung hin.
Häufige Fragen
Was passiert, wenn ich SameSite nicht setze?
In Chrome und Edge gilt das Cookie dann als Lax, mit einer Zwei-Minuten-Ausnahme für Formulare von außen. Firefox und Safari behandeln es anders. Deshalb immer ausdrücklich setzen.
Wann brauche ich SameSite=None?
Wenn dein Cookie in einem fremden Kontext gebraucht wird: in Widgets und iframes auf anderen Websites, bei Logins über mehrere Domains oder bei manchen Bezahlrücksprüngen. Dann immer zusammen mit Secure.
Ist Lax oder Strict besser für Login-Cookies?
Meist Lax. Mit Strict wäre jemand, der über einen Link in einer Mail auf deine Seite kommt, beim ersten Aufruf ausgeloggt. Strict passt für besonders sensible Bereiche ohne Einstieg von außen.
Warum verliert mein Shop nach der Zahlung die Sitzung?
Häufig, weil der Zahlungsdienst per Formular von seiner Website zurückschickt und das Sitzungs-Cookie mit Lax dabei nicht mitgeht. Abhilfe schafft ein Rücksprung per Link oder ein gezielt gesetztes None mit Secure.
Schützt SameSite vollständig vor CSRF?
Nein. Laut OWASP ist es eine zusätzliche Schutzschicht. Für Formulare mit Änderungen braucht es weiterhin echte CSRF-Token.
