First-Party- vs. Third-Party-Cookies & Einwilligung
First- und Third-Party-Cookies: Warum die Domain nicht über die Einwilligung entscheidet, was Browser heute blockieren und was Sie prüfen sollten.
Ein First-Party-Cookie wird für die Website gesetzt, die in der Adressleiste steht. Ein Third-Party-Cookie (auch Drittanbieter-Cookie) wird für eine andere Domain gesetzt, meist durch ein Skript, ein Pixel oder ein iframe, das diese Website von anderswo lädt. Für Browser, die Third-Party-Cookies zunehmend blockieren, ist der Unterschied sehr wichtig, für das Recht viel weniger. Ob ein Cookie eine Einwilligung braucht, hängt davon ab, wofür es verwendet wird, nicht davon, auf wessen Domain es liegt.
Der Unterschied und der Haken
Auf shop.example ist ein Cookie für shop.example ein First-Party-Cookie. Ein Cookie für die Domain eines Werbenetzwerks, das gesetzt wird, wenn die Seite des Shops das Pixel dieses Netzwerks lädt, ist ein Third-Party-Cookie: Der Browser speichert es unter der Domain des Werbenetzwerks, und es kann denselben Browser auf jeder anderen Website wiedererkennen, die dasselbe Pixel lädt. Genau das hat Third-Party-Cookies zum Rückgrat des websiteübergreifenden Trackings gemacht.
Der Haken: Ein First-Party-Cookie gehört nicht unbedingt Ihnen. Google Analytics schreibt sein Cookie _ga auf Ihre eigene Domain, und das Meta-Pixel schreibt _fbp ebenfalls auf Ihre Domain. Für den Browser sind beide First-Party-Cookies. Die Daten gehen an Google und Meta.
Die Aufsichtsbehörden haben das früh bemerkt. Die Stellungnahme der Artikel-29-Datenschutzgruppe von 2012 zur Cookie-Ausnahme beschreibt zwei Bedeutungen von „Dritter“: ein Cookie, das von einer anderen Organisation gesetzt wird, und ein Cookie, das von einer anderen Domain gesetzt wird. „Diese beiden Ansätze überschneiden sich zwar häufig, sind aber nicht immer gleichbedeutend.“ Die spanische AEPD geht in ihrem Cookie-Leitfaden noch weiter: Ein Cookie, das von der eigenen Domain des Betreibers ausgeliefert wird, kann nicht als First-Party-Cookie behandelt werden, wenn ein Dritter die damit erhobenen Daten für eigene Zwecke nutzt.
| Cookie | Was der Browser sieht | Wer die Daten nutzt | Einwilligung in der EU |
|---|---|---|---|
| Login-Sitzung | First-Party | Sie | Nicht nötig: unbedingt erforderlich |
_ga (Google Analytics) | First-Party | Sie, über Google | Nötig, abgesehen von engen nationalen Ausnahmen |
_fbp (Meta-Pixel) | First-Party | Meta, für Werbung | Nötig |
| Das Cookie eines Werbenetzwerks auf dessen eigener Domain | Third-Party | Das Werbenetzwerk | Nötig |
| Das Cookie eines sozialen Netzwerks, wenn ein angemeldetes Mitglied dessen Teilen-Button nutzt | Third-Party | Das soziale Netzwerk | Kann ausgenommen sein, nur für diese Teilen-Funktion |
Die letzte Zeile ist das eigene Beispiel der Artikel-29-Gruppe für ein Third-Party-Cookie, das ausgenommen sein kann, sofern es nur verwendet wird, um angemeldeten Mitgliedern die Teilen-Funktion bereitzustellen.
Warum das Etikett nicht über die Einwilligung entscheidet
Die EU-Regel, Art. 5 Abs. 3 der ePrivacy-Richtlinie, hängt an der Erforderlichkeit: Ist die Speicherung für einen Dienst, den der Besucher ausdrücklich angefordert hat, unbedingt erforderlich, oder dient sie allein der Übertragung einer Nachricht? Erst- oder Drittparteien erwähnt sie nicht.
Die Artikel-29-Gruppe behandelt das Etikett höchstens als Hinweis. First-Party-Sitzungs-Cookies seien „weit eher von der Einwilligung ausgenommen als persistente Third-Party-Cookies“, schreibt sie, aber: „Der Zweck des Cookies sollte stets die Grundlage für die Beurteilung sein, ob die Ausnahme erfolgreich angewendet werden kann, und nicht ein technisches Merkmal des Cookies.“ Third-Party-Cookies sind meist nicht unbedingt erforderlich, weil sie dem Dienst eines anderen dienen, nicht dem, für den der Besucher gekommen ist. Das ist eine Feststellung über den Zweck, nicht über Domains.
Für Third-Party-Cookies auf Ihrer Website sind Sie ebenfalls verantwortlich. Die Leitlinien der CNIL sagen, dass eine Organisation, die Tracker auf ihrer Website zulässt, auch Tracker Dritter, sicherstellen muss, dass tatsächlich ein Einwilligungsmechanismus vorhanden ist. Außerdem behandeln sie die Website und den Dritten als gemeinsam Verantwortliche, wenn beide gemeinsam entscheiden, warum und wie diese Tracker eingesetzt werden.
Wer Tracking in First-Party-Cookies oder serverseitige Setups verlagert, entkommt der Regel ebenfalls nicht. Die Leitlinien des EDSA zum technischen Anwendungsbereich von Art. 5 Abs. 3 entstanden unter anderem, weil neue Tracking-Methoden Cookies ersetzen, während manche Browser die Unterstützung für Third-Party-Cookies einstellen, und sie wenden die Regel auf Tracking-Pixel, Tracking-Links, IP-basiertes Tracking und eindeutige Kennungen an. Mehr dazu, wie der Zweck entscheidet, in Welche Cookies sind einwilligungspflichtig?.
Was Browser heute blockieren
| Browser | Third-Party-Cookies | Weitere Einschränkungen |
|---|---|---|
| Safari | Standardmäßig blockiert. Auf der Seite zur Tracking Prevention von WebKit heißt es: „Von dieser Blockierung gibt es keine Ausnahmen“, abgesehen von Zugriff, der über die Storage Access API gewährt wird, und einer Kompatibilitätslösung für Pop-ups | Per JavaScript erstellte Cookies werden nach 7 Tagen ohne Interaktion mit der Website gelöscht oder auf 24 Stunden begrenzt, wenn der Besucher über einen dekorierten Link eines bekannten Trackers kommt; über Third-Party-CNAME-Cloaking gesetzte Cookies sind auf 7 Tage begrenzt |
| Firefox | Bekannte Tracking-Cookies werden seit 2019 standardmäßig blockiert. Seit Juni 2022 hält der vollständige Cookie-Schutz (Total Cookie Protection) für alle Desktop-Nutzer die Cookies jeder Website in einem eigenen, getrennten Behälter | |
| Chrome | Dem Nutzer überlassen. Im April 2025 kündigte Google an, die Wahl weiterhin in den Chrome-Einstellungen anzubieten, ohne neue eigenständige Abfrage; im Inkognitomodus sind sie standardmäßig blockiert | Im Oktober 2025 stellte Google die meisten Privacy-Sandbox-Technologien ein, darunter Topics und Protected Audience, und behielt CHIPS, FedCM und Private State Tokens bei |
Daraus folgen zwei Dinge. Third-Party-Cookies funktionieren inzwischen ungleichmäßig: Für Besucher mit Safari und Firefox ist websiteübergreifendes Tracking über sie bereits weitgehend blockiert, während Chrome sie nicht abgeschafft hat. Und dass ein Browser ein Cookie blockiert, ist nicht dasselbe, wie wenn eine Website um Einwilligung bittet. Das Recht gilt für alles, was Ihre Website tatsächlich ausführt, in jedem Browser.
Was Sie auf Ihrer Website prüfen sollten
- Listen Sie jedes Cookie mit seiner Domain und seinem Zweck auf. Lassen Sie unseren Cookie-Checker eine Seite prüfen, oder scannen Sie die ganze Website.
- Finden Sie die First-Party-Cookies, die andere Unternehmen schreiben.
_ga,_fbpund ihre Verwandten sehen in den DevTools aus wie Ihre eigenen. Klassifizieren Sie sie danach, wer die Daten nutzt. - Beobachten Sie Anfragen, nicht nur Cookies. Ein Pixel kann Daten senden, ohne ein Cookie zu setzen, das Ihnen auffallen würde. Beim Fall Apoteket aus unserem Beitrag darüber, was Aufsichtsbehörden bestrafen, ging es darum, was ein Pixel gesendet hat, nicht um die Cookies, die es gesetzt hat.
- Stellen Sie auch serverseitige und CNAME-Setups unter Einwilligungsvorbehalt. Ein Tag auf Ihre eigene Subdomain zu verlegen, ändert, was der Browser sieht, nicht, was das Recht verlangt.
- Prüfen Sie die Signale, die Sie an Google senden. Wenn Sie Google-Tags nutzen, zeigt der Consent-Mode-Checker, was diese vor und nach einer Entscheidung empfangen.
Info
Browserregeln ändern sich häufiger als das Recht. Safari und Firefox haben ihre Standardeinstellungen seit 2019 verschärft, und Chrome hat seine Pläne mehr als einmal geändert. Bauen Sie Ihr Consent-Setup darauf auf, wofür jedes Cookie da ist, denn genau darauf schaut das Recht.
Wo Katla ins Spiel kommt
Die Scans von Katla erfassen First-Party- und Third-Party-Cookies gleichermaßen, jeweils mit Domain, Ablaufdatum und Flags sowie der Seite, auf der sie auftauchten, dazu die Tracking-Anfragen, die Seiten stellen. Jedes Cookie wird dann nach Zweck und Anbieter mit KI klassifiziert, sodass ein _ga auf Ihrer Domain als Analyse von Google eingeordnet wird und nicht als eines Ihrer eigenen Cookies.
Auf der Seite arbeitet der Cookie-Guard mit Cookies, die von Skripten in der Seite geschrieben werden: Im DSGVO-Modus blockiert er nicht funktionale Cookies vor der Einwilligung und löscht alle, die vorher gesetzt wurden. Ein echtes Third-Party-Cookie kommt in einer Antwort von einer anderen Domain an, also stoppen Sie es, indem Sie das Skript zurückhalten, das die Anfrage stellt: Skripte, die mit data-katla-category gekennzeichnet sind, warten, bis ihre Kategorie akzeptiert wurde.
Dieser Beitrag beschreibt, wie Cookies und Browser funktionieren, und fasst Leitlinien von Aufsichtsbehörden zusammen. Er ist keine Rechtsberatung.