Nur die Domain entscheidet über First-Party vs Third-Party Cookies

Was ist der Unterschied zwischen First-Party vs Third-Party Cookies?

Browser sortieren First-Party vs Third-Party Cookies mit einem einzigen Test und vergleichen dabei die Domain, die das Cookie gesetzt hat, mit der Domain in der Adressleiste: Das Cookie ist First-Party, also von der Domain der aufgerufenen Seite, wenn beide übereinstimmen, und Third-Party, also von einer fremden Domain, wenn nicht. Nichts im Inneren des Cookies geht in diesen Test ein, weder der Name noch der Wert noch der Eigentümer. Der MDN-Leitfaden zu Third-Party Cookies benennt die Regel direkt: "If the cookie domain and scheme match the current page the user is looking at (the URL shown in the browser's address bar), the cookie is considered to be from the same site as the page, and is referred to as a first-party cookie." Auf Deutsch: Wenn Cookie-Domain und Schema mit der aktuellen Seite übereinstimmen, die der Nutzer betrachtet (die in der Adressleiste des Browsers angezeigte URL), gilt das Cookie als von derselben Site wie die Seite stammend und heißt First-Party Cookie. Andere Domain oder anderes Schema, Third-Party Cookie.

Fast jede Seite im Netz beschreibt die Trennung als Ihr Cookie gegen das Cookie eines Werbetreibenden. Diese Darstellung ist falsch. Das Cookie eines Werbenetzwerks, gelesen auf der eigenen Site des Werbenetzwerks, ist First-Party; Ihr eigenes Login-Cookie, gelesen in einem iframe auf der Site eines Partners, ist Third-Party.

Warum ist dasselbe Cookie mal First-Party und mal Third-Party?

Die Kategorie gehört zum Lesevorgang, nicht zum Cookie. Ein gespeichertes Cookie trägt eine Domain, und der Browser wiederholt den Vergleich bei jeder Anfrage, sodass ein Lesevorgang auf einer anderen Top-Level-Site die Antwort umdreht.

Nehmen Sie ein Support-Widget, das ein Cookie auf widget.example setzt. Ein Besucher auf https://widget.example sendet dieses Cookie als First-Party Cookie, weil die Cookie-Domain mit der Adressleiste übereinstimmt. Derselbe Besucher öffnet https://shop.example, wo dasselbe Widget in einem iframe lädt. Der Browser vergleicht widget.example mit shop.example, findet keine Übereinstimmung, und das identische Cookie reist als Third-Party Cookie unter jeder Einschränkung, die der Browser dieser Kategorie auferlegt. Ein Cookie im Speicher, zwei Kategorien, pro Anfrage entschieden.

Was hat Chrome bei der Abschaffung von Third-Party Cookies tatsächlich getan?

Chrome hat sie gestrichen. Anthony Chavez, VP of Privacy Sandbox, schrieb am 22. April 2025, Google habe "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." Auf Deutsch: die Entscheidung getroffen, den bisherigen Ansatz beizubehalten und Nutzern in Chrome weiterhin die Wahl über Third-Party Cookies zu lassen, und werde keine neue eigenständige Abfrage für Third-Party Cookies ausrollen. Third-Party Cookies bleiben im normalen Surfmodus von Chrome standardmäßig aktiv, und die Steuerung bleibt in den Einstellungen unter Datenschutz und Sicherheit. Die Hilfedokumentation von Chrome hält fest, dass Third-Party Cookies im Inkognitomodus standardmäßig blockiert sind, die Sperre gilt also einem Surfmodus statt dem Browser.

Jeder Artikel, der noch ein Ausstiegsdatum zitiert, zitiert einen Plan, den Google zurückgezogen hat. Bauen Sie gegen das, was ausgeliefert wird: Safari blockiert, Firefox partitioniert, Chrome erlaubt außerhalb des Inkognitomodus.

Was machen Safari und Firefox mit Third-Party Cookies?

Safari löscht die Kategorie und Firefox teilt sie auf. John Wilander kündigte die vollständige Blockade am 24. März 2020 im WebKit-Blog in einem Satz an: "Cookies for cross-site resources are now blocked by default across the board." Auf Deutsch: Cookies für seitenübergreifende Ressourcen sind jetzt durchgehend standardmäßig blockiert. Die Tracking-Prevention-Policy von WebKit bestätigt, dass Intelligent Tracking Prevention "blocks all third-party cookies", also alle Third-Party Cookies blockiert, und einen einzigen Weg zurück offen lässt, die Storage Access API, die zuerst den Nutzer fragt.

Firefox ging den anderen Weg. Mozilla rollte Total Cookie Protection am 14. Juni 2022 weltweit an alle Nutzer aus, und es hält Third-Party Cookies innerhalb einer Grenze am Leben: "any time a website, or third-party content embedded in a website, deposits a cookie in your browser, that cookie is confined to the cookie jar assigned to only that website." Auf Deutsch: Immer wenn eine Website oder in eine Website eingebetteter Third-Party-Inhalt ein Cookie in Ihrem Browser ablegt, bleibt dieses Cookie auf das Cookie-Glas beschränkt, das nur dieser Website zugewiesen ist. Ein eingebetteter Tracker bekommt weiterhin auf jeder Site ein Cookie, auf der er erscheint, und jedes Mal ein anderes, was die seitenübergreifende Verknüpfung tötet, ohne das Widget zu töten.

First-Party vs Third-Party Cookies im Vergleich

Die letzte Zeile erklärt, warum die Blockade auf einer Seite gelandet ist. Third-Party Cookies zu blockieren zerstört die seitenübergreifende Verkabelung anderer Leute; First-Party Cookies zu blockieren würde das Web zerstören.

Was bricht, wenn Third-Party Cookies blockiert werden?

Seitenübergreifender Zustand bricht, und nur seitenübergreifender Zustand. Single Sign-on über einen Identitätsanbieter in einem iframe erkennt den Nutzer nicht mehr, ein eingebetteter Checkout oder ein Chat-Widget verliert den wiederkehrenden Kunden, und eine Werbeplattform verliert Conversion-Attribution und Frequency Capping, weil jedes davon einen Identifikator braucht, der auf zwei verschiedenen Top-Level-Sites gelesen wird.

Zwei Ersatzlösungen decken die Teile ab, die es wert sind, behalten zu werden. Die Storage Access API lässt einen eingebetteten Frame den Nutzer nach seinen unpartitionierten Cookies fragen. Partitionierte Cookies erledigen den Rest.

Wie verändern partitionierte Cookies das Bild?

Partitionierte Cookies behalten das Third-Party Cookie und entfernen die seitenübergreifende Verknüpfung, indem sie die Top-Level-Site zum Speicherschlüssel hinzufügen. MDN dokumentiert den Mechanismus als CHIPS, Cookies Having Independent Partitioned State, und führt ihn seit Dezember 2025 als Baseline newly available. Die Änderung ist eine einzige Zeile Schlüsselstruktur:

storage key = (top-level site, cookie domain) statt storage key = (cookie domain)

Arbeiten Sie ein Beispiel mit MDNs eigenen Werten durch. Ein Widget auf 3rd-party.example sendet Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;, während es auf site-a.example eingebettet ist, und der Browser speichert es unter {("https://site-a.example"), ("3rd-party.example")}. Auf site-b.example fragt das Widget nach dem Cookie, der Browser sucht nach {("https://site-b.example"), ("3rd-party.example")} und findet nichts. Das Widget funktioniert auf beiden Sites und verknüpft keine mit der anderen.

Überleben First-Party Cookies alles?

Nein, und die Ausnahme trifft zuerst Analytics. Die Tracking-Prevention-Policy von WebKit verpflichtet ITP auf "deleting all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction", auf Deutsch: das Löschen aller in JavaScript erzeugten Cookies und allen anderen skriptbeschreibbaren Speichers nach 7 Tagen ohne Nutzerinteraktion, was ein First-Party Cookie einschließt, das ein Analytics-Skript auf Ihrer eigenen Domain geschrieben hat. Die Regel richtet sich danach, wie das Cookie geschrieben wurde, nicht danach, wem die Domain gehört, auf der es liegt, sodass die 7-Tage-Grenze für Safari-Cookies jeden clientseitigen Identifikator verkürzt.

Der sichtbare Effekt sind aufgeblähte Zahlen neuer Besucher, weil ein wiederkehrender Besucher nach Ablauf der Grenze ohne Identifikator ankommt und eine neue Sitzung startet. Setzen Sie Identifikatoren serverseitig in einem Set-Cookie Response-Header, wenn sie die Grenze überleben sollen.

Was bedeutet das für die Messung Ihrer eigenen Site?

Analytics, das sich auf ein Third-Party Cookie stützt, misst den normalen Surfmodus von Chrome und wenig sonst. Den Identifikator auf ein First-Party Cookie zu verschieben erweitert die Abdeckung und trifft die ITP-Grenze, weshalb Messung immer weiter Richtung Server driftet: Lesen Sie die Argumente für serverseitiges Tracking, bevor Sie zum dritten Mal einen clientseitigen Identifikator neu bauen.

Keine der beiden Kategorien entkommt dem Einwilligungsrecht. Artikel 5(3) der ePrivacy-Richtlinie fragt, ob Informationen auf dem Gerät gespeichert oder von ihm gelesen werden, sodass ein First-Party Analytics-Cookie ihn genauso auslöst wie ein Third-Party Cookie, wofür ein Consent-Banner existiert. Gar keinen Identifikator zu speichern entfernt den Auslöser, und cookielose Analytics behandelt, was Sie das kostet.

Flowsery ist genau so gebaut. Seine datenschutzfreundliche Analytics kommt ohne Cookies aus, wird in der EU gehostet und ist GDPR by design, liefert ein einziges Skript unter 10 KB und wendet kein Daten-Sampling an, landet also nie auf einer der beiden Seiten der Trennung zwischen First-Party und Third-Party.

Häufig gestellte Fragen

Ist ein First-Party Cookie immer sicher vor Browser-Blockaden?

Nein. Safaris ITP löscht in JavaScript erzeugte Cookies zusammen mit anderem skriptbeschreibbarem Speicher nach 7 Tagen ohne Nutzerinteraktion, und das gilt auf Ihrer eigenen Domain. Ein First-Party Cookie, das der Server in einem Set-Cookie Response-Header setzt, fällt nicht unter diese Regel. Entscheidend ist, wie das Cookie geschrieben wurde, nicht wem die Domain gehört.

Schaut der Browser darauf, wem die Domain gehört?

Nein. Der Browser vergleicht Domain und Schema des Cookies mit der Top-Level-Seite in der Adressleiste und mit sonst nichts. Eigentum, Firma und Zweck gehen nie in den Vergleich ein, weshalb das Cookie eines Werbetreibenden auf dessen eigener Site First-Party ist.

Kann ein Cookie zugleich First-Party und Third-Party sein?

Ja, und dasselbe gespeicherte Cookie wechselt bei jeder Anfrage zwischen beiden. Auf der Domain gelesen, die es gesetzt hat, ist das Cookie First-Party. Aus einem iframe auf einer anderen Top-Level-Site gelesen, ist das identische Cookie Third-Party und erbt jede Third-Party-Einschränkung.

Warum braucht ein Third-Party Cookie SameSite=None und Secure?

Seitenübergreifende Anfragen tragen ein Cookie nur, wenn es mit SameSite=None markiert ist, denn der Browser-Standard ist SameSite=Lax. MDN hält fest: "if SameSite=None is set then the Secure attribute must also be set", auf Deutsch: Wenn SameSite=None gesetzt ist, muss auch das Attribut Secure gesetzt sein, was es auf HTTPS beschränkt. Ohne beide Attribute sendet ein moderner Browser das Cookie nie seitenübergreifend.

Hat Google jemals Third-Party Cookies aus Chrome entfernt?

Nein. Anthony Chavez schrieb am 22. April 2025, Google werde "maintain our current approach to offering users third-party cookie choice in Chrome", also den bisherigen Ansatz beibehalten und Nutzern in Chrome die Wahl über Third-Party Cookies lassen, und keine eigenständige Abfrage ausrollen. Chrome erlaubt Third-Party Cookies im normalen Surfen standardmäßig und blockiert sie im Inkognitomodus standardmäßig, laut Chromes Hilfedokumentation.

Löscht Firefox Third-Party Cookies so wie Safari?

Nein, Firefox isoliert sie stattdessen. Total Cookie Protection, seit 14. Juni 2022 weltweit Standard, beschränkt jedes Cookie auf "the cookie jar assigned to only that website", auf Deutsch: das Cookie-Glas, das nur dieser Website zugewiesen ist, sodass ein eingebetteter Tracker auf jeder Site, auf der er erscheint, ein eigenes Cookie bekommt. Die Einbettung funktioniert weiter, und das seitenübergreifende Profil kommt nie zustande.

Wofür steht CHIPS?

CHIPS steht für Cookies Having Independent Partitioned State, den Mechanismus, den MDN hinter partitionierten Cookies dokumentiert. Er fügt die Top-Level-Site zum Speicherschlüssel des Cookies hinzu, sodass dieselbe Cookie-Domain auf jeder einbettenden Site einen eigenen Wert erhält. MDN führt CHIPS als Baseline newly available seit Dezember 2025.

Was ist die Storage Access API?

Die Storage Access API lässt ein eingebettetes Iframe den Browser um Zugriff auf seine unpartitionierten Cookies bitten, wobei zuerst der Nutzer gefragt wird. Safaris WebKit-Tracking-Prevention-Richtlinie nennt sie als den einzigen Weg zurück, nachdem alle Third-Party Cookies blockiert wurden. Partitionierte Cookies decken den Rest ab, den seitenübergreifender Zustand braucht, um weiter zu funktionieren.

Brauchen auch First-Party Cookies eine Einwilligung?

Artikel 5(3) der ePrivacy-Richtlinie fragt, ob Informationen auf dem Gerät gespeichert oder von ihm gelesen werden, nicht welcher Domain sie gehören, sodass ein First-Party Analytics Cookie dieselbe Einwilligungspflicht auslöst wie ein Third-Party Cookie. Ein Consent-Banner existiert genau dafür, unabhängig von der Cookie-Kategorie. Wird gar keine Kennung gespeichert, entfällt der Auslöser vollständig.

Warum werden wiederkehrende Besucher manchmal als neue Besucher gezählt?

Ein wiederkehrender Besucher, der nach Safaris 7-Tage-ITP-Grenze zurückkehrt, hat keine Kennung mehr, sodass Analytics eine neue Sitzung startet und ihn als neu zählt. Die Regel gilt für jedes clientseitig per JavaScript geschriebene Cookie, auch für First-Party Analytics-Skripte auf der eigenen Domain. Kennungen serverseitig per Set-Cookie-Response-Header zu setzen, umgeht die Grenze vollständig.