Cookie-Typen: Ein umfassender technischer Leitfaden

Nicht alle Cookies sind gleich. Der Cookie-Typ bestimmt, wie lange ein Cookie bestehen bleibt, wer es auslesen kann, wie sicher es übertragen wird und – ganz entscheidend – ob eine Einwilligung der Nutzer erforderlich ist. Diese Unterschiede zu verstehen, ist sowohl für die Compliance als auch für die technische Umsetzung unerlässlich.

Session-Cookies vs. persistente Cookies

Die grundlegendste Unterscheidung betrifft die Lebensdauer eines Cookies.

Session-Cookies

Ein Session-Cookie besteht nur für die Dauer einer Browsersitzung. Es besitzt kein Expires- oder Max-Age-Attribut. Sobald die Nutzer ihren Browser schließen, wird das Cookie gelöscht.

Set-Cookie: cart_id=xyz789; Path=/; Secure; HttpOnly

Session-Cookies werden typischerweise eingesetzt für:

• Aufrechterhaltung des Login-Status während eines Besuchs
• Inhalte des Warenkorbs
• CSRF-Schutz-Token
• Mehrstufige Formulardaten

Da Session-Cookies nicht dauerhaft gespeichert werden, sind sie aus Datenschutzsicht in der Regel weniger invasiv. Dennoch erfordern sie eine Einwilligung, sofern sie für den von den Nutzern angeforderten Dienst nicht unbedingt erforderlich sind.

Persistente Cookies

Ein persistentes Cookie besitzt ein ausdrückliches Ablaufdatum. Es übersteht Browser-Neustarts und verbleibt auf dem Gerät der Nutzer, bis es abläuft oder manuell gelöscht wird.

Set-Cookie: preferences_lang=en; Path=/; Max-Age=31536000; Secure

Dieses Cookie bleibt ein Jahr lang bestehen (31.536.000 Sekunden). Häufige Einsatzzwecke sind:

• „Angemeldet bleiben“-Funktion beim Login
• Sprach- und Design-Einstellungen
• Analyse-Kennungen (Google-Analytics-Cookies bleiben bis zu 2 Jahre bestehen)
• Werbe-Tracking (manche Werbe-Cookies bleiben 13 Monate oder länger bestehen)

Persistente Cookies unterliegen im Rahmen der Datenschutzvorschriften einer strengeren Prüfung. Die CNIL (die französische Datenschutzbehörde) hat eine maximale Cookie-Lebensdauer von 13 Monaten empfohlen, und auch die Einwilligung muss mindestens alle 13 Monate erneuert werden.

Erstanbieter- vs. Drittanbieter-Cookies

Diese Unterscheidung steht im Zentrum der Datenschutzdebatte und wirkt sich unmittelbar auf die Einwilligungspflichten aus.

Erstanbieter-Cookies

Ein Erstanbieter-Cookie wird von der Domain gesetzt, die die Nutzer tatsächlich besuchen. Wenn Sie example.com aufrufen, ist jedes von example.com gesetzte Cookie ein Erstanbieter-Cookie.

Erstanbieter-Cookies werden für zentrale Website-Funktionen genutzt: Sitzungen, Einstellungen und Analysen, die der Website-Betreiber selbst durchführt. Sie können nur von der Domain ausgelesen werden, die sie gesetzt hat.

Beispiel: Sie besuchen shop.example.com. Der Server setzt ein Cookie namens session_id. Dieses Cookie wird ausschließlich an shop.example.com und dessen Subdomains gesendet. Keine andere Website kann darauf zugreifen.

Drittanbieter-Cookies

Ein Drittanbieter-Cookie wird von einer anderen Domain gesetzt als der, die die Nutzer besuchen. Wenn example.com ein Werbeskript von ads.tracker.com lädt und dieses Skript ein Cookie unter der Domain tracker.com setzt, handelt es sich um ein Drittanbieter-Cookie.

So funktioniert das seitenübergreifende Tracking. Das tracker.com-Cookie wird bei jeder Anfrage an tracker.com mitgesendet, unabhängig davon, welche Website die Anfrage ausgelöst hat. Sind die Skripte von tracker.com auf 10.000 Websites eingebunden, können sie denselben Nutzer über alle 10.000 Seiten hinweg beobachten.

Drittanbieter-Cookies sind das Hauptziel sowohl regulatorischer Durchsetzungsmaßnahmen als auch von Beschränkungen auf Browserebene:

• Safari blockiert Drittanbieter-Cookies seit 2020 standardmäßig (ITP)
• Firefox blockiert bekannte Drittanbieter-Tracker standardmäßig (ETP)
• Chrome wendet sich mit seiner Privacy-Sandbox-Initiative von Drittanbieter-Cookies ab
• Regulatorische Durchsetzungsmaßnahmen richten sich ganz überwiegend gegen Drittanbieter-Tracking-Cookies

Secure-Cookies

Ein Cookie mit dem Attribut Secure wird ausschließlich über HTTPS-Verbindungen gesendet. Es wird niemals über unverschlüsseltes HTTP übertragen.

Set-Cookie: auth_token=secret123; Secure

Dadurch wird verhindert, dass ein Man-in-the-Middle-Angreifer das Cookie über eine unsichere Verbindung abfängt. Jedes Cookie, das sensible Informationen enthält – Sitzungskennungen, Authentifizierungs-Token, personenbezogene Daten –, sollte stets als Secure gekennzeichnet werden.

Aus Compliance-Sicht könnte das Fehlen des Secure-Flags bei sensiblen Cookies als Versäumnis gewertet werden, geeignete technische Maßnahmen nach Art. 32 DSGVO (Sicherheit der Verarbeitung) umzusetzen.

HttpOnly-Cookies

Auf ein Cookie mit dem Attribut HttpOnly kann JavaScript nicht über document.cookie zugreifen. Es wird nur mit HTTP-Anfragen an den Server gesendet.

Set-Cookie: session_id=abc123; HttpOnly

Dies ist eine entscheidende Sicherheitsmaßnahme. Cross-Site-Scripting-Angriffe (XSS) versuchen häufig, Cookies zu stehlen, indem sie JavaScript einschleusen, das document.cookie ausliest. Das HttpOnly-Flag verhindert diesen Angriffsvektor vollständig.

Session- und Authentifizierungs-Cookies sollten fast immer HttpOnly sein. Cookies, die von clientseitigem JavaScript ausgelesen werden müssen (etwa Einstellungs-Cookies, die die Benutzeroberfläche beeinflussen), können nicht HttpOnly sein.

SameSite-Cookies

Das Attribut SameSite steuert, ob ein Cookie bei seitenübergreifenden Anfragen gesendet wird. Es wurde eingeführt, um Cross-Site-Request-Forgery-Angriffe (CSRF) einzudämmen und Websites mehr Kontrolle über das Verhalten seitenübergreifender Cookies zu geben.

SameSite=Strict

Das Cookie wird nur bei Anfragen gesendet, die von derselben Website stammen. Klickt ein Nutzer auf other.com auf einen Link, der zu your-site.com führt, wird das Cookie mit dieser ersten Anfrage nicht gesendet.

Dies ist die sicherste Einstellung, kann jedoch legitime Funktionen beeinträchtigen. Klickt ein Nutzer beispielsweise in einer E-Mail auf einen Link zu Ihrer Website, würde sein Session-Cookie nicht gesendet, und er würde als abgemeldet erscheinen.

SameSite=Lax

Das Cookie wird bei Navigationen auf oberster Ebene (Klick auf einen Link) gesendet, jedoch nicht bei seitenübergreifenden Unteranfragen (Laden von Bildern, Frames oder AJAX-Anfragen von einer anderen Website). Dies ist in modernen Browsern die Standardeinstellung, wenn kein SameSite-Attribut angegeben ist.

Lax bietet eine sinnvolle Balance zwischen Sicherheit und Benutzerfreundlichkeit. Es verhindert, dass Drittanbieter-Websites authentifizierte Aktionen auf Ihrer Website auslösen, während die normale Navigation über Links weiterhin funktioniert.

SameSite=None

Das Cookie wird bei allen Anfragen gesendet, einschließlich seitenübergreifender Anfragen. Dies ist erforderlich, damit Drittanbieter-Cookies funktionieren. Ein Cookie mit SameSite=None muss zudem das Attribut Secure besitzen.

Set-Cookie: tracking_id=xyz; SameSite=None; Secure

Jedes Cookie, das in einem seitenübergreifenden Kontext funktionieren muss (eingebettete Widgets, Drittanbieter-Authentifizierung, seitenübergreifendes Tracking), muss SameSite=None verwenden. Dies wird zunehmend relevant, da Browser ihre Standard-Cookie-Richtlinien verschärfen.

Zombie-Cookies und Supercookies

Diese verdienen Erwähnung, da sie Versuche darstellen, Datenschutzkontrollen zu umgehen:

• Zombie-Cookies sind Cookies, die sich nach dem Löschen selbst wiederherstellen. Sie funktionieren typischerweise, indem sie dieselbe Kennung in mehreren Speichermechanismen ablegen (Cookies, localStorage, IndexedDB, Flash-LSOs) und denjenigen, der überlebt, nutzen, um die anderen neu zu erzeugen. Diese Praxis gilt weithin als irreführend und war bereits Gegenstand von Durchsetzungsmaßnahmen.
• Supercookies sind Tracking-Mechanismen, die auf einer Ebene unterhalb normaler Cookies arbeiten – etwa durch Header-Injection auf ISP-Ebene (Verizons UIDH) oder HSTS-basiertes Fingerprinting. Sie sind für Nutzer äußerst schwer zu kontrollieren oder zu löschen.

Sowohl Zombie-Cookies als auch Supercookies sind eindeutig unvereinbar mit den Anforderungen der DSGVO und der ePrivacy-Richtlinie. Ihre Verwendung würde einen Verstoß gegen die Grundsätze der Transparenz, Rechtmäßigkeit und Datenminimierung darstellen.

Vergleichstabelle

Typ	Lebensdauer	Geltungsbereich	In der Regel einwilligungspflichtig?	Wichtige Einsatzzwecke
Session	Nur Browsersitzung	Erstanbieter	Nur wenn nicht erforderlich	Login-Status, Warenkorb, CSRF-Token
Persistent (Erstanbieter)	Tage bis Jahre	Erstanbieter	In der Regel ja	Einstellungen, Analyse, „Angemeldet bleiben“
Persistent (Drittanbieter)	Tage bis Jahre	Seitenübergreifend	Fast immer ja	Werbung, Retargeting, Social-Widgets
Secure	Variiert	Nur HTTPS	Abhängig vom Zweck	Jedes sensible Cookie
HttpOnly	Variiert	Nur serverseitig	Abhängig vom Zweck	Session-IDs, Auth-Token
SameSite=Strict	Variiert	Nur dieselbe Website	Abhängig vom Zweck	CSRF-sensible Vorgänge
SameSite=Lax	Variiert	Dieselbe Website + Navigation auf oberster Ebene	Abhängig vom Zweck	Allgemeines Sitzungsmanagement
SameSite=None	Variiert	Alle Kontexte (erfordert Secure)	Fast immer ja	Drittanbieter-Einbettungen, seitenübergreifende Authentifizierung

Was das für die Compliance bedeutet

Der Cookie-Typ wirkt sich unmittelbar auf Ihre Compliance-Pflichten aus:

1. Erstanbieter-Session-Cookies, die unbedingt erforderlich sind (Login-Sitzungen, Warenkörbe, CSRF-Token), sind gemäß Art. 5 Abs. 3 der ePrivacy-Richtlinie von der Einwilligungspflicht ausgenommen.
2. Persistente Erstanbieter-Cookies für Analyse, Einstellungen oder Funktionalität erfordern in der Regel eine Einwilligung – wobei einige Datenschutzbehörden unter bestimmten Bedingungen begrenzte Ausnahmen für Erstanbieter-Analysen zulassen.
3. Drittanbieter-Cookies jeglicher Art erfordern nahezu immer eine ausdrückliche vorherige Einwilligung. Es gibt nur sehr wenige legitime Ausnahmen.
4. Sicherheitsattribute (Secure, HttpOnly, SameSite) ändern nichts an den Einwilligungspflichten, ihre Verwendung belegt jedoch eine gute Sicherheitspraxis – was seinerseits eine Anforderung der DSGVO ist.

Genau zu wissen, welche Cookies Ihre Website setzt – und um welchen Typ es sich jeweils handelt –, ist die Grundlage jedes Compliance-Programms. Der Scanner von Passiro identifiziert und klassifiziert automatisch jedes Cookie auf Ihrer Website, einschließlich Drittanbieter-Cookies, die von eingebetteten Skripten gesetzt werden, von denen Sie möglicherweise gar nichts wissen.

Nachdem wir nun die Typen verstanden haben, werfen wir einen Blick darauf, wie Cookies in Einwilligungskategorien eingeteilt werden – das Klassifizierungssystem, das bestimmt, wie sie in Ihrem Cookie-Banner erscheinen.