Cookie-Arten erklärt: Session, Persistent, First-Party, Third-Party
Alle Cookie-Arten technisch erklärt: Session vs. Persistent, First-Party vs. Third-Party, Cookie-Attribute, Consent-Pflicht nach TDDDG und die Zukunft von Third-Party-Cookies.
Cookies sind seit 1994 ein fester Bestandteil des Webs. Doch “Cookie” ist nicht gleich “Cookie” — die Unterschiede zwischen den verschiedenen Arten sind technisch, rechtlich und praktisch relevant. Wer wissen will, welche Cookies Consent brauchen und welche nicht, muss die Grundlagen verstehen.
In diesem Artikel erklären wir alle Cookie-Arten, ihre technischen Eigenschaften und die rechtlichen Konsequenzen nach TDDDG und DSGVO.
Was sind Cookies technisch?
Ein Cookie ist ein kleines Datenfragment, das ein Webserver im Browser des Nutzers speichert. Technisch funktioniert es so:
- Der Server sendet einen
Set-Cookie-Header in der HTTP-Response - Der Browser speichert das Cookie lokal
- Bei jedem weiteren Request an denselben Server sendet der Browser das Cookie automatisch mit
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600
Ein Cookie besteht aus einem Name-Wert-Paar und optionalen Attributen, die das Verhalten steuern. Die Attribute entscheiden, ob ein Cookie harmlos oder datenschutzrechtlich problematisch ist.
Session-Cookies vs. Persistent Cookies
Der wichtigste Unterschied bei Cookies ist ihre Lebensdauer.
Session-Cookies
Session-Cookies haben kein Ablaufdatum (Expires oder Max-Age). Sie werden gelöscht, sobald der Browser geschlossen wird. Sie dienen typischerweise der Sitzungsverwaltung.
Persistent Cookies
Persistent Cookies haben ein definiertes Ablaufdatum und überleben das Schließen des Browsers. Sie können Tage, Monate oder sogar Jahre bestehen bleiben.
| Eigenschaft | Session-Cookie | Persistent Cookie |
|---|---|---|
| Lebensdauer | Bis Browser geschlossen wird | Definiertes Ablaufdatum |
| Expires/Max-Age | Nicht gesetzt | Gesetzt (z.B. 1 Jahr) |
| Typischer Einsatz | Login-Session, Warenkorb, CSRF-Token | Sprache, Login-Erinnerung, Tracking |
| Consent nötig? | Meist nein (technisch notwendig) | Kommt auf den Zweck an |
| Beispiele | PHPSESSID, JSESSIONID, connect.sid | _ga (2 Jahre), _fbp (3 Monate) |
Rechtlich relevant: Die Lebensdauer allein entscheidet nicht über die Consent-Pflicht. Ein Session-Cookie für Tracking braucht Consent, ein Persistent Cookie für die Spracheinstellung nicht.
First-Party vs. Third-Party Cookies
Die zweite zentrale Unterscheidung betrifft die Herkunft des Cookies.
First-Party Cookies
First-Party Cookies werden von der Domain gesetzt, die der Nutzer gerade besucht. Wenn du example.com besuchst und ein Cookie mit Domain=example.com gesetzt wird, ist es ein First-Party Cookie.
Third-Party Cookies
Third-Party Cookies werden von einer anderen Domain gesetzt als der, die der Nutzer besucht. Wenn du example.com besuchst und ein Cookie von facebook.com oder doubleclick.net gesetzt wird, ist es ein Third-Party Cookie.
Third-Party Cookies entstehen typischerweise durch:
- Eingebettete Werbeanzeigen (Ad-Netzwerke)
- Social-Media-Plugins (Like-Button, Share-Widget)
- Analytics-Dienste (wenn über Drittanbieter-Domain)
- Embedded Content (YouTube-Videos, Google Maps)
| Eigenschaft | First-Party Cookie | Third-Party Cookie |
|---|---|---|
| Gesetzt von | Besuchte Domain | Andere Domain |
| Cross-Site-Tracking | Nicht möglich | Möglich (Nutzer über Websites hinweg verfolgen) |
| Browser-Support | Voll unterstützt | Zunehmend blockiert (Safari, Firefox, Chrome) |
| Typischer Einsatz | Session, Einstellungen, eigenes Analytics | Werbung, Retargeting, Cross-Site-Tracking |
| Consent nötig? | Nur wenn nicht technisch notwendig | Fast immer (Tracking-Zweck) |
Das SameSite-Attribut
Das SameSite-Attribut steuert, ob ein Cookie bei Cross-Site-Requests mitgesendet wird. Es ist die wichtigste Browser-seitige Schutzmaßnahme gegen Cross-Site Request Forgery (CSRF) und ungewolltes Tracking.
| SameSite-Wert | Verhalten | Einsatz |
|---|---|---|
Strict | Cookie wird nur bei Same-Site-Requests gesendet | Sicherheitskritische Cookies (CSRF-Token) |
Lax | Cookie wird bei Navigation zur Seite gesendet, nicht bei eingebetteten Requests | Login-Sessions, allgemeine Cookies (Browser-Default seit 2020) |
None | Cookie wird immer gesendet, auch bei Cross-Site-Requests | Third-Party-Cookies (erfordert Secure-Attribut) |
Set-Cookie: session=abc; SameSite=Lax; Secure; HttpOnly
Set-Cookie: tracking=xyz; SameSite=None; Secure
Wichtig: Seit 2020 setzen Chrome, Firefox und Edge Cookies standardmäßig auf SameSite=Lax, wenn kein Attribut angegeben wird. Cookies mit SameSite=None müssen zwingend das Secure-Attribut haben (nur HTTPS).
Alle Cookie-Attribute im Überblick
| Attribut | Wert | Funktion | Datenschutz-Relevanz |
|---|---|---|---|
Domain | .example.com | Bestimmt, für welche Domain(s) das Cookie gilt | Weite Domain = mehr Subdomains können das Cookie lesen |
Path | /shop | Beschränkt das Cookie auf einen URL-Pfad | Einschränkung reduziert Exposition |
Expires | Datum | Absolutes Ablaufdatum | Lange Laufzeit = mehr Datenschutz-Risiko |
Max-Age | Sekunden | Relative Lebensdauer ab Setzen | Gleiche Wirkung wie Expires |
Secure | (Flag) | Cookie nur über HTTPS senden | Pflicht für sensible Daten |
HttpOnly | (Flag) | Cookie nicht per JavaScript lesbar | Schutz vor XSS-Angriffen |
SameSite | Strict/Lax/None | Cross-Site-Verhalten (siehe oben) | Schutz vor Tracking und CSRF |
Partitioned | (Flag) | Cookie an Top-Level-Site gebunden (CHIPS) | Neue Technologie, reduziert Cross-Site-Tracking |
Partitioned Cookies (CHIPS)
Mit dem Partitioned-Attribut (Cookies Having Independent Partitioned State) führt Chrome eine neue Methode ein: Third-Party-Cookies werden an die Top-Level-Site gebunden. Ein Cookie, das widget.com auf site-a.com setzt, ist nicht dasselbe Cookie wie das, das widget.com auf site-b.com setzt. Cross-Site-Tracking wird damit technisch verhindert, während eingebettete Dienste weiterhin funktionieren.
Set-Cookie: __Host-widget_session=abc; Secure; Path=/; SameSite=None; Partitioned
Welche Cookies brauchen Consent?
SS 25 TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz, in Kraft seit Juli 2024, als Nachfolger des TTDSG) regelt die Consent-Pflicht für Cookies. Die Regel ist einfach:
Einwilligung erforderlich für alle Cookies, die nicht unbedingt erforderlich sind, um den vom Nutzer ausdrücklich gewünschten Dienst bereitzustellen.
Entscheidungsbaum
- Ist das Cookie technisch notwendig für die vom Nutzer angeforderte Funktion?
- Ja: Kein Consent nötig (SS 25 Abs. 2 Nr. 2 TDDDG)
- Nein: Weiter zu Frage 2
- Dient das Cookie ausschließlich der Übertragung einer Nachricht über ein Telekommunikationsnetz?
- Ja: Kein Consent nötig (SS 25 Abs. 2 Nr. 1 TDDDG)
- Nein: Consent ist erforderlich (SS 25 Abs. 1 TDDDG)
Beispiele nach Kategorien
| Kategorie | Beispiele | Cookie-Namen | Consent? |
|---|---|---|---|
| Technisch notwendig | Session-Management, Warenkorb, CSRF-Token, Lastverteilung, Cookie-Consent-Speicherung | PHPSESSID, cart_id, csrf_token, _compliso_consent | Nein |
| Funktional | Spracheinstellung, Theme (Dark Mode), Video-Player-Einstellungen | lang, theme, volume | Umstritten — wenn nutzerinitiiert: eher nein |
| Analytics | Besucherzählung, Seitenaufrufe, Conversion-Tracking | _ga, _gid, _gat, plausible_* | Ja |
| Marketing | Retargeting, personalisierte Werbung, Affiliate-Tracking | _fbp, _gcl_au, IDE, fr, _uetsid | Ja |
| Social Media | Like-Button-Status, Login via Social | datr, c_user, xs (Facebook) | Ja |
Sonderfall serverseitiges Analytics: Tools wie Plausible oder Matomo können ohne Cookies betrieben werden. Wenn kein Cookie gesetzt wird, greift SS 25 TDDDG nicht — aber die DSGVO (IP-Adress-Verarbeitung) kann trotzdem relevant sein.
Cookie-Alternativen: Brauchen die auch Consent?
Cookies sind nicht die einzige Speichertechnologie im Browser. SS 25 TDDDG spricht bewusst nicht von “Cookies”, sondern von “Speicherung von Informationen in der Endeinrichtung oder Zugriff auf bereits gespeicherte Informationen”. Das umfasst:
| Technologie | Kapazität | Lebensdauer | Consent nötig? |
|---|---|---|---|
| localStorage | 5-10 MB | Dauerhaft (bis gelöscht) | Ja, wenn nicht technisch notwendig |
| sessionStorage | 5-10 MB | Bis Tab geschlossen | Ja, wenn nicht technisch notwendig |
| IndexedDB | Bis zu Hunderten MB | Dauerhaft | Ja, wenn nicht technisch notwendig |
| Cache API | Variabel | Variabel | Ja, wenn nicht technisch notwendig |
| Browser Fingerprinting | - | - | Ja (Zugriff auf Geräteinformationen) |
Wichtig: Der Umstieg von Cookies auf localStorage ändert an der Consent-Pflicht nichts. Wer Tracking-Daten in localStorage statt in Cookies speichert, braucht trotzdem eine Einwilligung. Die Speichertechnologie ist irrelevant — der Zweck entscheidet.
Third-Party Cookie Phase-Out in Chrome
Google hat angekündigt, Third-Party-Cookies in Chrome nicht komplett zu blockieren, sondern Nutzern die Wahl zu lassen (Stand 2025). Stattdessen setzt Google auf die Privacy Sandbox mit neuen APIs:
| API | Zweck | Ersetzt |
|---|---|---|
| Topics API | Interessenbasierte Werbung ohne individuelles Tracking | Third-Party-Tracking-Cookies |
| Protected Audience (FLEDGE) | On-Device Auktionen für Retargeting | Retargeting-Cookies |
| Attribution Reporting | Conversion-Messung ohne Cross-Site-Tracking | Conversion-Cookies |
| CHIPS | Partitioned Cookies für eingebettete Dienste | Unpartitioned Third-Party-Cookies |
Was bedeutet das für Website-Betreiber?
- Safari und Firefox blockieren Third-Party-Cookies bereits seit Jahren
- Chrome (ca. 65 % Marktanteil) gibt Nutzern die Kontrolle
- Langfristig werden Third-Party-Cookies an Bedeutung verlieren
- First-Party-Datenstrategien werden wichtiger
- Consent-Management bleibt Pflicht — auch für neue APIs
So findest du alle Cookies auf deiner Website
Manuell kannst du Cookies in den Browser-DevTools finden:
- Öffne die DevTools (F12)
- Gehe zu “Application” (Chrome) bzw. “Storage” (Firefox)
- Klicke auf “Cookies” und wähle deine Domain
- Prüfe jedes Cookie: Name, Wert, Domain, Ablaufdatum, SameSite, Secure, HttpOnly
Problem: Diese Methode zeigt nur Cookies auf der aktuellen Seite. Cookies auf Unterseiten, Cookies nach bestimmten Interaktionen oder Cookies, die erst nach einigen Sekunden gesetzt werden, werden leicht übersehen.
Praxis-Checkliste
- Alle Cookies auf der Website identifiziert (inkl. Unterseiten)
- Cookies nach Kategorien sortiert (notwendig, funktional, analytics, marketing)
- Consent-Pflicht für jedes Cookie bewertet (SS 25 TDDDG)
- Cookie-Banner konfiguriert mit korrekten Kategorien
- Nicht-notwendige Cookies werden vor Consent tatsächlich blockiert
- Cookie-Laufzeiten geprüft (CNIL-Empfehlung: max. 13 Monate)
- localStorage und sessionStorage auf Tracking-Nutzung geprüft
- Datenschutzerklärung listet alle Cookies mit Namen, Zweck, Anbieter und Laufzeit
- Third-Party-Cookies identifiziert und AVVs mit Anbietern abgeschlossen
- Cookie-Audit wird regelmäßig wiederholt (mindestens quartalsweise)
Cookies automatisch erkennen mit Compliso
Den kompletten Cookie-Audit manuell durchzuführen ist aufwendig und fehleranfällig. Der Compliso Scanner crawlt deine Website automatisch, erkennt alle gesetzten Cookies (inkl. Third-Party und localStorage), kategorisiert sie und prüft, ob Cookies vor Consent gesetzt werden.
Du erhältst eine vollständige Cookie-Liste mit Name, Domain, Laufzeit und Kategorie — fertig für deinen Cookie-Banner und deine Datenschutzerklärung.
Erfahre mehr über die Cookie-Analyse von Compliso oder teste den Demo-Scanner jetzt kostenlos und finde heraus, welche Cookies deine Website setzt.
Deine Website DSGVO-konform machen?
Compliso prüft deine Website automatisch auf Cookies, Tracker, Dark Patterns und Accessibility-Probleme.