Serverseitige Cookies mit Cloudflare und ssGTM: Consent und ITP-Grenzen

Ein Cloudflare Worker kann Cookies per HTTP-Antwort setzen und Messanfragen an einen Server-Container weiterleiten. Das bietet Kontrolle über Datenwege und Cookie-Attribute. Eine garantierte Umgehung von Safaris Intelligent Tracking Prevention (ITP), eine feste Speicherdauer oder automatische Rechtskonformität folgt daraus nicht.

Was ITP tatsächlich begrenzt

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ür auf der Zielseite per JavaScript erzeugte Cookies eine 24-Stunden-Grenze auslösen. Nicht jeder URL-Parameter erfüllt diese Erkennungsbedingungen.

Auch HTTP-Cookies können unter die Sieben-Tage-Grenze fallen: WebKit berücksichtigt erkanntes Drittanbieter-CNAME- und IP-Cloaking. Dabei zählt die konkrete Beziehung zur Hauptseite, nicht pauschal die Nutzung eines CDN. IP-Erkennung ist heuristisch und kann sich ändern. Ein gleicher Hostname oder eine Einwilligung liefert keine Ausnahmegarantie gegen Browserregeln.

Max-Age beschreibt die angeforderte Lebensdauer. Browsergrenzen, private Sitzungen, Bereinigung und manuelles Löschen können die tatsächliche Speicherung verkürzen. Fehlt eine Kennung und erzeugt der Server eine neue UUID, entsteht eine neue Kennung; die frühere Identität wird damit nicht wiederhergestellt.

Cookie-Attribute ohne falsche Sicherheitsversprechen

Ein nachvollziehbarer Lebenszyklus

Für eine zustimmungspflichtige Analysekennung muss die Freigabe vor dem Setzen und vor der entsprechenden Verarbeitung geprüft werden. Ein frei gesendeter Requestparameter mit dem Wert „granted“ ist kein belastbarer Einwilligungsnachweis. Die konkrete CMP-Anbindung muss die aktuelle Auswahl, deren Zweck und den Widerruf berücksichtigen.

1. Ein dedizierter Endpunkt verarbeitet nur den vorgesehenen Requesttyp und eine geprüfte Herkunft; Zustandsänderungen benötigen einen passenden Schutz vor fremdausgelösten Aufrufen.
2. Ohne gültige Freigabe entsteht keine neue Analysekennung. Bei Widerruf wird ein vorhandenes Cookie passend gelöscht und die weitere Verwendung beendet.
3. Mit Freigabe kann ein vorhandener zulässiger Wert weiterverwendet werden. Ein fehlender Wert führt nur bei erlaubter Neuanlage zu einer frischen zufälligen Kennung.
4. Die personalisierte Antwort erhält eine ausdrückliche Cache-Sperre. Gemeinsame Seiten-Caches dürfen keine Besucherkennungen aus Antworten wiederverwenden.
5. Der serverseitige Client und jedes Ziel-Tag erhalten eine dokumentierte Zuordnung, die Zustimmung, fehlende Kennungen und Widerruf berücksichtigt.

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ält weder CMP-Prüfung noch Endpunkt- oder Proxycode und ist keine fertige Worker-Implementierung.

Cache-Control: private, no-store
Set-Cookie: __Host-fp_id=RANDOM_IDENTIFIER; Max-Age=2592000; Path=/; Secure; HttpOnly; SameSite=Lax

Das Präfix __Host- verlangt in unterstützenden Browsern Secure, Path=/ und das Weglassen von Domain. Für den Widerruf auf demselben Host:

Cache-Control: private, no-store
Set-Cookie: __Host-fp_id=; Max-Age=0; Path=/; Secure; HttpOnly; SameSite=Lax

Bereits vorhandene Cookies mit anderem Namen, Domain- oder Pfadumfang benötigen eigene passende Löschungen. Nach dem Widerruf darf der nächste Aufruf nicht sofort eine neue Kennung erzeugen. Der tatsächliche Browserbestand und die ausgehenden Requests sind dafür aussagekräftiger als der Löschheader allein.

Die erste Anfrage enthält das neue Cookie noch nicht

Bei einer Weiterleitung mit fetch(request) ist der Request bereits zum Backend unterwegs, bevor ein nachträglich ergänzter Set-Cookie-Header den Browser erreicht. Ein in der Antwort neu gesetzter Wert erscheint daher nicht rückwirkend im ersten Backend-Request. Die Integration muss diese Reihenfolge ausdrücklich behandeln, statt ein automatisches Mapping zu behaupten.

Eine eigene fp_id oder __Host-fp_id ist außerdem nicht automatisch eine GA4- oder Google-Ads-Client-ID. Der zuständige Server-Client, die Zielschemas und mögliche Auswirkungen auf Nutzer- und Sitzungszählung müssen geprüft werden. Eine parallel eingeführte Kennung kann die bisherigen Identitätsmodelle verändern.

Google Tag Gateway ist ein eigener Baustein

Google Tag Gateway (GTG) liefert Google-Skripte und Messanfragen über konfigurierte Pfade der eigenen Webinfrastruktur aus. Cloudflare bietet dafür eine eigene Integration; ein selbst geschriebener Cookie-Worker ist nicht Voraussetzung und nicht automatisch Bestandteil dieser Integration.

GTG und ein ssGTM-Container erfüllen unterschiedliche Aufgaben. Ein gleicher Origin kann Verbindungen wiederverwenden, garantiert aber weder exakt dieselbe IP über alle Anfragen noch eine bestimmte Latenz. Weiterleitung und Verarbeitung bleiben zusätzliche 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.

Vorhandene _ga-Cookies gezielt behandeln

Eine separate HTTP-Verlängerung von _ga benötigt ein geprüftes Zusammenspiel mit dem Google-Tag. Das Skript muss auf dieses Cookie zugreifen können; HttpOnly passt daher nicht zu einer gewöhnlichen skriptgelesenen _ga-Konfiguration. Name, Domain und Pfad müssen zum vorhandenen Cookie passen, sonst entstehen mehrere Cookies statt einer Verlängerung.

cookie_domain: 'auto' und cookie_update beeinflussen das Verhalten des Google-Tags. cookie_update: false verhindert die laufende tagseitige Aktualisierung, bietet aber keine ITP-Ausnahme. Eine zusätzliche Verlängerung darf keine alte Entscheidung oder bewusste Löschung übergehen. Die dokumentierte Google-Standardlaufzeit ist ebenfalls keine garantierte Browserlaufzeit.

Fragen und Antworten

Zerstört ein Cookie automatisch den Cloudflare-Cache?

Nein. Der dokumentierte Standard-Cache-Key enthält nicht pauschal alle Cookie-Werte. Angepasste Cache-Keys und Bypass-Regeln können Cookies jedoch berücksichtigen. Set-Cookie in Antworten beeinflusst die Cachebarkeit zusätzlich. Eine Regel zum Ignorieren eines Cookies ist nur vertretbar, wenn Inhalt und Zugriffsrechte tatsächlich unabhängig davon sind.

Ist ein MISS bereits ein Nachweis für ein Cookieproblem?

Nein. Leere oder abgelaufene Caches, Cache-Regeln und Antwortheader haben ebenfalls Einfluss. Wiederholte Requests und die wirksame Konfiguration müssen gemeinsam ausgewertet werden.

Erkennt der Server das Ablaufdatum am Cookie-Header?

Nein. Der Request enthält Cookie-Namen und Werte, nicht die ursprünglichen Attribute wie Max-Age. Ein Erneuerungsfenster benötigt eine separat festgelegte Zeitlogik; eine bloße Prüfung auf Vorhandensein reicht nicht.

Welche Prüfungen sind vor Einsatz nötig?

Freigabe, Ablehnung, Widerruf, erneuter Aufruf, erster Request ohne Kennung, parallele Requests, Cookie-Geltungsbereich und Cache-Isolation gehören in einen Browser- und Integrationstest. Die Tests müssen die tatsächlich verwendeten Safari-/Chrome-Versionen und die konkrete GTG-/ssGTM-Konfiguration abdecken. Eine allgemeine Lebensdauer- oder Rechtsgarantie ergibt sich daraus nicht.

Quellen

• Tracking Prevention in WebKit
• WebKit CNAME defense
• WebKit Private Browsing 2.0
• WebKit Tracking Prevention Policy
• Cloudflare default cache behavior
• Cloudflare cache keys
• Cloudflare Workers Cache API
• Cloudflare Google Tag Gateway
• Google Tag Gateway cookie handling
• Google first-party script serving
• Google cookie configuration
• MDN Set-Cookie
• Full Third-Party Cookie Blocking (WebKit)
• Cloudflare Workers documentation
• Google Analytics: Cookie-Nutzung auf Websites
• Chrome for Developers: Cookie Expires and Max-Age attributes now have upper limit
• RFC 6265: HTTP State Management Mechanism, Section 5.3
• Richtlinie 2002/58/EG (Datenschutzrichtlinie für elektronische Kommunikation)