{"id":8502,"date":"2026-08-12T12:13:00","date_gmt":"2026-08-12T10:13:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8502"},"modified":"2026-10-24T03:17:09","modified_gmt":"2026-10-24T01:17:09","slug":"first-party-cookie-restoration-itp-uberleben-mit-cloudflare-workers-ssgtm","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-marketing-de\/first-party-cookie-restoration-itp-uberleben-mit-cloudflare-workers-ssgtm\/","title":{"rendered":"Serverseitige Cookies mit Cloudflare und ssGTM: Consent und ITP-Grenzen"},"content":{"rendered":"

Ein Cloudflare Worker kann Cookies per HTTP-Antwort setzen und Messanfragen an einen Server-Container weiterleiten. Das bietet Kontrolle \u00fcber Datenwege und Cookie-Attribute. Eine garantierte Umgehung von Safaris Intelligent Tracking Prevention (ITP), eine feste Speicherdauer oder automatische Rechtskonformit\u00e4t folgt daraus nicht.<\/p>\n

Was ITP tats\u00e4chlich begrenzt<\/h2>\n

WebKit beschreibt die Entfernung skriptbeschreibbarer Speicherung nach sieben Tagen Safari-Nutzung ohne Interaktion mit der Website. Gemeint sind Nutzungstage von Safari, nicht einfach sieben Kalendertage. Erkannte Link-Dekoration kann f\u00fcr auf der Zielseite per JavaScript erzeugte Cookies eine 24-Stunden-Grenze ausl\u00f6sen. Nicht jeder URL-Parameter erf\u00fcllt diese Erkennungsbedingungen.<\/p>\n

Auch HTTP-Cookies k\u00f6nnen unter die Sieben-Tage-Grenze fallen: WebKit ber\u00fccksichtigt erkanntes Drittanbieter-CNAME- und IP-Cloaking. Dabei z\u00e4hlt die konkrete Beziehung zur Hauptseite, nicht pauschal die Nutzung eines CDN. IP-Erkennung ist heuristisch und kann sich \u00e4ndern. Ein gleicher Hostname oder eine Einwilligung liefert keine Ausnahmegarantie gegen Browserregeln.<\/p>\n

Max-Age<\/code> beschreibt die angeforderte Lebensdauer. Browsergrenzen, private Sitzungen, Bereinigung und manuelles L\u00f6schen k\u00f6nnen die tats\u00e4chliche Speicherung verk\u00fcrzen. Fehlt eine Kennung und erzeugt der Server eine neue UUID, entsteht eine neue Kennung; die fr\u00fchere Identit\u00e4t wird damit nicht wiederhergestellt.<\/p>\n

\"Freigabe,
Freigabe, begrenzte Cookies, ausdr\u00fcckliche Zielzuordnung und Widerruf; Browserregeln begrenzen die Speicherung.<\/figcaption><\/figure>\n

Cookie-Attribute ohne falsche Sicherheitsversprechen<\/h2>\n\n\n\n\n\n\n\n\n\n
Attribut<\/th>\nWirkung und Grenze<\/th>\n<\/tr>\n<\/thead>\n
HttpOnly<\/code><\/td>\nVerhindert direkten JavaScript-Zugriff auf den Cookie-Wert. XSS kann weiterhin Aktionen im Seitenkontext ausf\u00fchren; ITP-Immunit\u00e4t entsteht nicht.<\/td>\n<\/tr>\n
Secure<\/code><\/td>\nBeschr\u00e4nkt die Cookie-\u00dcbertragung auf sichere Verbindungen. Die Verbindung vom Worker zum Backend braucht ebenfalls eine passende Transportkonfiguration.<\/td>\n<\/tr>\n
SameSite=Lax<\/code><\/td>\nSteuert das Mitsenden bei seiten\u00fcbergreifenden Anfragen. Das Attribut macht einen Anbieter nicht zur eigenen Organisation.<\/td>\n<\/tr>\n
Kein Domain<\/code><\/td>\nErzeugt ein hostgebundenes Cookie. Eine Domainangabe erweitert den Geltungsbereich auf passende Subdomains und verhindert keine CNAME-Erkennung.<\/td>\n<\/tr>\n
Path=\/<\/code><\/td>\nGilt f\u00fcr alle Pfade des passenden Hosts; der Pfad ist keine belastbare Sicherheitsgrenze.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Ein nachvollziehbarer Lebenszyklus<\/h2>\n

F\u00fcr eine zustimmungspflichtige Analysekennung muss die Freigabe vor dem Setzen und vor der entsprechenden Verarbeitung gepr\u00fcft werden. Ein frei gesendeter Requestparameter mit dem Wert \u201egranted\u201c ist kein belastbarer Einwilligungsnachweis. Die konkrete CMP-Anbindung muss die aktuelle Auswahl, deren Zweck und den Widerruf ber\u00fccksichtigen.<\/p>\n

    \n
  1. Ein dedizierter Endpunkt verarbeitet nur den vorgesehenen Requesttyp und eine gepr\u00fcfte Herkunft; Zustands\u00e4nderungen ben\u00f6tigen einen passenden Schutz vor fremdausgel\u00f6sten Aufrufen.<\/li>\n
  2. Ohne g\u00fcltige Freigabe entsteht keine neue Analysekennung. Bei Widerruf wird ein vorhandenes Cookie passend gel\u00f6scht und die weitere Verwendung beendet.<\/li>\n
  3. Mit Freigabe kann ein vorhandener zul\u00e4ssiger Wert weiterverwendet werden. Ein fehlender Wert f\u00fchrt nur bei erlaubter Neuanlage zu einer frischen zuf\u00e4lligen Kennung.<\/li>\n
  4. Die personalisierte Antwort erh\u00e4lt eine ausdr\u00fcckliche Cache-Sperre. Gemeinsame Seiten-Caches d\u00fcrfen keine Besucherkennungen aus Antworten wiederverwenden.<\/li>\n
  5. Der serverseitige Client und jedes Ziel-Tag erhalten eine dokumentierte Zuordnung, die Zustimmung, fehlende Kennungen und Widerruf ber\u00fccksichtigt.<\/li>\n<\/ol>\n

    Das folgende Headerbeispiel beschreibt ein neues, hostgebundenes Cookie mit beispielhaften 30 Tagen. Der Platzhalter ist durch einen sicher erzeugten Zufallswert zu ersetzen. Der Ausschnitt enth\u00e4lt weder CMP-Pr\u00fcfung noch Endpunkt- oder Proxycode und ist keine fertige Worker-Implementierung.<\/p>\n

    Cache-Control: private, no-store\nSet-Cookie: __Host-fp_id=RANDOM_IDENTIFIER; Max-Age=2592000; Path=\/; Secure; HttpOnly; SameSite=Lax<\/code><\/pre>\n
    Das Pr\u00e4fix __Host-<\/code> verlangt in unterst\u00fctzenden Browsern Secure<\/code>, Path=\/<\/code> und das Weglassen von Domain<\/code>. F\u00fcr den Widerruf auf demselben Host:<\/p>\n
    Cache-Control: private, no-store\nSet-Cookie: __Host-fp_id=; Max-Age=0; Path=\/; Secure; HttpOnly; SameSite=Lax<\/code><\/pre>\n
    Bereits vorhandene Cookies mit anderem Namen, Domain- oder Pfadumfang ben\u00f6tigen eigene passende L\u00f6schungen. Nach dem Widerruf darf der n\u00e4chste Aufruf nicht sofort eine neue Kennung erzeugen. Der tats\u00e4chliche Browserbestand und die ausgehenden Requests sind daf\u00fcr aussagekr\u00e4ftiger als der L\u00f6schheader allein.<\/p>\n
    Die erste Anfrage enth\u00e4lt das neue Cookie noch nicht<\/h2>\n
    Bei einer Weiterleitung mit fetch(request)<\/code> ist der Request bereits zum Backend unterwegs, bevor ein nachtr\u00e4glich erg\u00e4nzter Set-Cookie<\/code>-Header den Browser erreicht. Ein in der Antwort neu gesetzter Wert erscheint daher nicht r\u00fcckwirkend im ersten Backend-Request. Die Integration muss diese Reihenfolge ausdr\u00fccklich behandeln, statt ein automatisches Mapping zu behaupten.<\/p>\n
    Eine eigene fp_id<\/code> oder __Host-fp_id<\/code> ist au\u00dferdem nicht automatisch eine GA4- oder Google-Ads-Client-ID. Der zust\u00e4ndige Server-Client, die Zielschemas und m\u00f6gliche Auswirkungen auf Nutzer- und Sitzungsz\u00e4hlung m\u00fcssen gepr\u00fcft werden. Eine parallel eingef\u00fchrte Kennung kann die bisherigen Identit\u00e4tsmodelle ver\u00e4ndern.<\/p>\n
    Google Tag Gateway ist ein eigener Baustein<\/h2>\n
    Google Tag Gateway (GTG) liefert Google-Skripte und Messanfragen \u00fcber konfigurierte Pfade der eigenen Webinfrastruktur aus. Cloudflare bietet daf\u00fcr eine eigene Integration; ein selbst geschriebener Cookie-Worker ist nicht Voraussetzung und nicht automatisch Bestandteil dieser Integration.<\/p>\n
    GTG und ein ssGTM-Container erf\u00fcllen unterschiedliche Aufgaben. Ein gleicher Origin kann Verbindungen wiederverwenden, garantiert aber weder exakt dieselbe IP \u00fcber alle Anfragen noch eine bestimmte Latenz. Weiterleitung und Verarbeitung bleiben zus\u00e4tzliche Arbeit. Laut Google verarbeitet GTG Google-First-Party-Cookies; andere mitgesendete First-Party-Cookies werden verworfen. Eine eigene Kennung wird deshalb nicht allein durch Einschalten von GTG nutzbar.<\/p>\n
    Vorhandene _ga-Cookies gezielt behandeln<\/h2>\n
    Eine separate HTTP-Verl\u00e4ngerung von _ga<\/code> ben\u00f6tigt ein gepr\u00fcftes Zusammenspiel mit dem Google-Tag. Das Skript muss auf dieses Cookie zugreifen k\u00f6nnen; HttpOnly<\/code> passt daher nicht zu einer gew\u00f6hnlichen skriptgelesenen _ga<\/code>-Konfiguration. Name, Domain und Pfad m\u00fcssen zum vorhandenen Cookie passen, sonst entstehen mehrere Cookies statt einer Verl\u00e4ngerung.<\/p>\n
    cookie_domain: 'auto'<\/code> und cookie_update<\/code> beeinflussen das Verhalten des Google-Tags. cookie_update: false<\/code> verhindert die laufende tagseitige Aktualisierung, bietet aber keine ITP-Ausnahme. Eine zus\u00e4tzliche Verl\u00e4ngerung darf keine alte Entscheidung oder bewusste L\u00f6schung \u00fcbergehen. Die dokumentierte Google-Standardlaufzeit ist ebenfalls keine garantierte Browserlaufzeit.<\/p>\n
    Fragen und Antworten<\/h2>\n
    Zerst\u00f6rt ein Cookie automatisch den Cloudflare-Cache?<\/h3>\n
    Nein. Der dokumentierte Standard-Cache-Key enth\u00e4lt nicht pauschal alle Cookie-Werte. Angepasste Cache-Keys und Bypass-Regeln k\u00f6nnen Cookies jedoch ber\u00fccksichtigen. Set-Cookie<\/code> in Antworten beeinflusst die Cachebarkeit zus\u00e4tzlich. Eine Regel zum Ignorieren eines Cookies ist nur vertretbar, wenn Inhalt und Zugriffsrechte tats\u00e4chlich unabh\u00e4ngig davon sind.<\/p>\n
    Ist ein MISS bereits ein Nachweis f\u00fcr ein Cookieproblem?<\/h3>\n
    Nein. Leere oder abgelaufene Caches, Cache-Regeln und Antwortheader haben ebenfalls Einfluss. Wiederholte Requests und die wirksame Konfiguration m\u00fcssen gemeinsam ausgewertet werden.<\/p>\n
    Erkennt der Server das Ablaufdatum am Cookie-Header?<\/h3>\n
    Nein. Der Request enth\u00e4lt Cookie-Namen und Werte, nicht die urspr\u00fcnglichen Attribute wie Max-Age. Ein Erneuerungsfenster ben\u00f6tigt eine separat festgelegte Zeitlogik; eine blo\u00dfe Pr\u00fcfung auf Vorhandensein reicht nicht.<\/p>\n
    Welche Pr\u00fcfungen sind vor Einsatz n\u00f6tig?<\/h3>\n
    Freigabe, Ablehnung, Widerruf, erneuter Aufruf, erster Request ohne Kennung, parallele Requests, Cookie-Geltungsbereich und Cache-Isolation geh\u00f6ren in einen Browser- und Integrationstest. Die Tests m\u00fcssen die tats\u00e4chlich verwendeten Safari-\/Chrome-Versionen und die konkrete GTG-\/ssGTM-Konfiguration abdecken. Eine allgemeine Lebensdauer- oder Rechtsgarantie ergibt sich daraus nicht.<\/p>\n
    Quellen<\/h2>\n