Wie ein fehlendes Attribut über Session-Cookie vs. persistentes Cookie entscheidet

Was ist der Unterschied zwischen einem Session-Cookie und einem persistenten Cookie?

Der ganze Unterschied bei Session-Cookie vs. persistentes Cookie ist ein Attribut: Ein persistentes Cookie hat ein Datum in Expires oder eine Angabe in Sekunden in Max-Age, ein Session-Cookie hat keines von beiden. RFC 6265, der aktuelle Cookie-Standard, sagt, dass ein Cookie ohne beide Attribute aufbewahrt wird, bis "the current session is over", so wie der Browser das definiert. Ein Cookie mit einem der beiden Attribute wird aufbewahrt, bis diese Zeit verstrichen ist oder bis der Browser oder der Nutzer es vorher löscht.

Set-Cookie: sid=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Max-Age=2592000; Path=/

Die erste Zeile setzt ein Session-Cookie. Die zweite setzt ein persistentes Cookie, das 2,592,000 Sekunden hält, also 30 Tage. Der Name des Cookies spielt keine Rolle. Ein Cookie namens session_id mit Max-Age ist persistent, und ein Cookie namens remember_me ohne Ablaufzeit ist ein Session-Cookie.

Wie entscheidet ein Browser, welche Art von Cookie er erhalten hat?

Ein Browser entscheidet, indem er die Attribute in einer festen Reihenfolge liest, so wie es der Speicheralgorithmus in Abschnitt 5.3 von RFC 6265 vorgibt. Hat das Cookie ein Max-Age, setzt der Browser das persistent-flag des Cookies auf true und nimmt Max-Age für die Ablaufzeit. Andernfalls, wenn es ein Expires hat, ist das Flag true und Expires legt die Ablaufzeit fest. Sonst ist das Flag false, und die Ablaufzeit wird auf "the latest representable date." gesetzt.

Innerhalb der Spezifikation hat ein Session-Cookie also das spätestmögliche Ablaufdatum, und nur das persistent-flag mit dem Wert false sorgt dafür, dass es entfernt wird. Derselbe Abschnitt sagt: "When 'the current session is over' (as defined by the user agent), the user agent MUST remove from the cookie store all cookies with the persistent-flag set to false."

Zwei weitere Regeln zählen in der Praxis:

• Max-Age schlägt Expires. Abschnitt 4.1.2.2: "If a cookie has both the Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie."
• Null löscht. Nach Abschnitt 5.2.2 setzt ein Max-Age von 0 oder weniger die Ablaufzeit auf "the earliest representable date and time", das Cookie wird also sofort entfernt. Max-Age=0 zu senden ist der Standardweg, ein Cookie vom Server aus zu löschen.

Die beiden Cookie-Seiten von MDN widersprechen sich darin, wessen Uhr ein Datum in Expires verwendet. Der Leitfaden zu HTTP-Cookies sagt, Expires-Daten seien "relative to the client the cookie is being set on", ein Server mit abweichender Zeit könne also Fehler verursachen. Die Referenz zu Set-Cookie sagt, der Server setze Expires "with a value relative to its own internal clock", und Firefox sowie Chromium-basierte Browser glichen den Uhrenunterschied über den Header Date aus, während die Spezifikation "does not indicate if/how the value should be corrected by the recipient." Der Rat des Leitfadens gilt so oder so: Max-Age ist "less error-prone", weil es die Sekunden ab dem Moment zählt, in dem der Browser das Cookie erhält.

Wann endet eine Session tatsächlich?

Kein Standard sagt, wann eine Session endet, und diese Lücke ist der Grund, warum sich Session-Cookies nicht so verhalten, wie ihr Name vermuten lässt. RFC 6265 überlässt das dem Browser mit der Formulierung "as defined by the user agent", die sowohl im Abschnitt zu den Attributen als auch im Abschnitt zur Speicherung steht.

Die beiden Cookie-Seiten von MDN beschreiben das Ergebnis von entgegengesetzten Enden. Die Referenz zu Set-Cookie sagt, eine Session "finishes when the client shuts down, after which the session cookie is removed", und warnt dann, dass Browser mit einer Funktion für Session Restore auch Session-Cookies wiederherstellen, "as if the browser was never closed." Der Leitfaden zu HTTP-Cookies geht weiter: "The browser defines when the 'current session' ends, and some browsers use session restoring when restarting. This can cause session cookies to last indefinitely."

Mit eingeschaltetem Session Restore kann ein Session-Cookie ein persistentes Cookie mit einer Ablaufzeit von einer Woche überleben. Code, der ein Session-Cookie als Garantie für einen Logout behandelt, verlässt sich auf eine Browsereinstellung, die er nicht sehen kann. Lassen Sie die Authentifizierung deshalb auch auf dem Server ablaufen.

Ein Session-Cookie hat außerdem nichts mit einer Session in der Analytics zu tun. Google Analytics 4 speichert seinen Session-Status in einem Cookie namens _ga_<container-id>, das sein Hilfe-Center mit einer Standard-Ablaufzeit von 2 Jahren und der Beschreibung "Used to persist session state." führt. Die Analytics-Session ist ein Zeitfenster, das das Tool berechnet, beschrieben unter was als Session zählt. Das Cookie, das sie sich merkt, ist persistent.

Wie lange kann ein persistentes Cookie halten?

Ein persistentes Cookie kann in Chrome und in dem Entwurf, der RFC 6265 ablösen wird, bis zu 400 Tage halten. RFC 6265 setzte keine Obergrenze. Sein Nachfolger draft-ietf-httpbis-rfc6265bis-22 vom 1. Dezember 2025, den der IETF-Datatracker in der Warteschlange des RFC Editor führt, fügt Abschnitt 5.5 hinzu: Der Browser "MUST limit the maximum age of the cookie", und "The limit SHOULD NOT be greater than 400 days (34560000 seconds) in the future." Ein Expires oder Max-Age über der Grenze "MUST be reduced to the limit."

Chrome setzt die Grenze bereits durch. Der Blog Chrome for Developers hält fest: "As of Chrome release M104 (August 2022) cookies can no longer set an expiration date more than 400 days in the future." Damit stehen zwei veröffentlichte Zahlen im Widerspruch. Google Analytics dokumentiert Standardwerte von 2 Jahren für _ga und _ga_<container-id>, und Chrome, ebenfalls von Google, kürzt jedes solche Datum beim Speichern des Cookies auf 400 Tage.

Safari setzt für eine Art von Cookie eine deutlich niedrigere Grenze. Die Ankündigung von WebKit zu Intelligent Tracking Prevention 2.1 vom 21. Februar 2019 sagt: "All persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry." Derselbe Beitrag ergänzt: "Session cookies are not affected, they remain session cookies." Cookies, die ein Server über den Header Set-Cookie setzt, fallen nicht unter diese Regel. Alle Safari-Regeln stehen unter wie das 7-Tage-Cookie-Limit von Safari funktioniert.

RFC 6265 bittet auch Server um Zurückhaltung. Abschnitt 7.3 sagt, Server "SHOULD promote user privacy by selecting reasonable cookie expiration periods based on the purpose of the cookie", und gibt ein Beispiel, das die Begriffe vermischt: "a typical session identifier might reasonably be set to expire in two weeks." Ein Session-Identifier liegt also oft in einem persistenten Cookie.

Brauchen Session-Cookies und persistente Cookies eine Einwilligung?

Nach EU-Recht ist keine der beiden Arten wegen ihrer Lebensdauer von der Einwilligung ausgenommen, und beide sind nur dann ausgenommen, wenn sie für einen vom Nutzer angefragten Dienst unbedingt erforderlich sind. Die Stellungnahme 04/2012 der Artikel-29-Datenschutzgruppe zur Ausnahme von der Cookie-Einwilligung, angenommen am 7. Juni 2012, definiert die beiden Begriffe: Ein Session-Cookie ist ein Cookie, "der automatisch gelöscht wird, wenn der Nutzer seinen Browser schließt", und ein persistentes Cookie ist ein Cookie, "der auf dem Endgerät des Nutzers bis zu einem festgelegten Ablaufdatum (das Minuten, Tage oder auch mehrere Jahre in der Zukunft liegen kann) gespeichert bleibt."

Die Stellungnahme behandelt die Lebensdauer dann als Indiz, nicht als Test. Sie sagt, First-Party-Sitzungscookies seien "mit wesentlich höherer Wahrscheinlichkeit von der Einwilligungspflicht ausgenommen als persistente Third-Party-Cookies", und im selben Absatz: "Die Gefahr für den Datenschutz ergibt sich weniger aus den im Cookie enthaltenen Informationen als aus dem Zweck oder den Zwecken der Verarbeitung." Ihr deutlichstes Beispiel ist der Login. Authentifizierungs-Cookies, die für die Dauer der Session gelten, sind ausgenommen, aber "Persistente Anmelde-Cookies, in denen ein Authentifizierungstoken über mehrere Browsersitzungen hinweg gespeichert wird, fallen nicht unter die Ausnahmeregelung nach Kriterium B", und eine Checkbox mit einem Hinweis wie "Angemeldet bleiben (verwendet Cookies)" wird als geeignetes Mittel genannt, die Einwilligung dafür einzuholen.

Nationale Aufsichtsbehörden ergänzen Zahlen. Die französische CNIL erlaubt in ihren Leitlinien zu Tools für die Reichweitenmessung, dass solche Tracker ohne Einwilligung auskommen, wenn ihre Lebensdauer auf einen Zeitraum begrenzt ist, "comme c'est le cas d'une durée de treize mois" (zum Beispiel 13 Monate), sie nicht "prorogée automatiquement lors des nouvelles visites" wird (bei neuen Besuchen automatisch verlängert) und die erhobenen Daten höchstens "vingt-cinq mois" (25 Monate) aufbewahrt werden. Ein Analytics-Cookie, das seine Ablaufzeit bei jedem Besuch zurücksetzt, verfehlt die zweite Bedingung, ganz gleich, wie kurz seine Lebensdauer ist.

Führen Sie in einer Cookie-Tabelle in der Datenschutzerklärung die Lebensdauer jedes Cookies so an, wie sie tatsächlich gesetzt ist, also "Session" oder eine Dauer, neben seinem Zweck und der Angabe, ob es ein First-Party- oder Third-Party-Cookie ist. Dieselben Fragen gelten für Daten im Browserspeicher, die die Seite zu Local Storage vs. Cookies behandelt.

Häufig gestellte Fragen

Wie mache ich ein Cookie zu einem Session-Cookie?

Lassen Sie beim Setzen sowohl das Attribut Expires als auch Max-Age weg. Der Browser behält das Cookie dann, bis die Session endet, so wie der Browser das definiert. Die MDN-Seite zu document.cookie nennt dieselbe Regel für per Script gesetzte Cookies: Ist keines von beiden angegeben, läuft das Cookie am Ende der Session ab.

Werden Session-Cookies gelöscht, wenn ich einen Tab schließe?

Nein. Das Schließen eines Tabs beendet die Browser-Session nicht. Session-Cookies werden entfernt, wenn der Browser geschlossen wird, außer Session Restore holt sie zurück.

Was gilt, wenn ein Cookie sowohl Expires als auch Max-Age hat?

Max-Age gewinnt. RFC 6265 Abschnitt 4.1.2.2 sagt, Max-Age "has precedence and controls the expiration date of the cookie." MDN ergänzt, dass Max-Age weniger fehleranfällig ist, weil ein Datum in Expires von Uhren abhängt, die voneinander abweichen können.

Wie lösche ich ein persistentes Cookie?

Setzen Sie dasselbe Cookie erneut, mit demselben Namen, derselben Domain und demselben Pfad, und mit einem Max-Age von 0 oder einem Datum in Expires, das in der Vergangenheit liegt. RFC 6265 behandelt ein Max-Age von null oder weniger als das früheste darstellbare Datum, der Browser entfernt das Cookie also sofort.

Sind Session-Cookies datenschutzfreundlicher als persistente Cookies?

Session-Cookies leben von vornherein kürzer, was begrenzt, wie lange sie Besuche miteinander verknüpfen können. Die Artikel-29-Datenschutzgruppe beurteilte Cookies trotzdem nach ihrem Zweck: Ein Session-Cookie für Tracking braucht eine Einwilligung, und ein persistentes Cookie kann ausgenommen sein, wenn der Nutzer das angefragt hat, was es tut.

Macht der private Modus persistente Cookies zu Session-Cookies?

Im Ergebnis ja. RFC 6265 Abschnitt 7.2 sagt, ein Browser, der anbietet, die persistente Speicherung zu verhindern, "MUST treat all received cookies as if the persistent-flag were set to false", und nennt den privaten Modus als verbreitete Form dieser Einstellung. Jedes Cookie ist weg, wenn die private Session geschlossen wird.

Ist ein Session-Cookie dasselbe wie eine Session in Google Analytics?

Nein. Die Analytics-Session ist ein Zeitfenster, das das Tool berechnet, und das Cookie, das sie speichert, ist persistent. Google Analytics 4 legt den Session-Status in _ga_<container-id> ab, das die Hilfe mit einer Standardlaufzeit von 2 Jahren aufführt.

Wie lange kann ein persistentes Cookie in Chrome halten?

Bis zu 400 Tage. Seit Chrome M104 im August 2022 darf ein Cookie kein Ablaufdatum mehr setzen, das mehr als 400 Tage in der Zukunft liegt, ein längeres Expires oder Max-Age wird daher gekürzt. Der Entwurf rfc6265bis nennt dieselbe Obergrenze.

Überleben Session-Cookies einen Neustart des Browsers?

Laut Spezifikation nicht, in der Praxis aber oft. RFC 6265 überlässt das Ende der Session dem Browser, und Browser mit Session-Wiederherstellung holen Session-Cookies zurück, als wäre der Browser nie geschlossen worden. MDN warnt, dass sie dadurch unbegrenzt bestehen können.

Braucht ein Login-Cookie für "Angemeldet bleiben" in der EU eine Einwilligung?

Ja. Die Stellungnahme 04/2012 der Artikel-29-Datenschutzgruppe sagt, dass persistente Login-Cookies, die ein Authentifizierungs-Token über Browser-Sessions hinweg speichern, nicht ausgenommen sind, und nennt eine Checkbox mit dem Hinweis "Angemeldet bleiben (verwendet Cookies)" als Weg, die Einwilligung einzuholen. Authentifizierungs-Cookies, die nur die Session überdauern, sind ausgenommen.