{"id":10334,"date":"2026-09-02T12:35:00","date_gmt":"2026-09-02T10:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10334"},"modified":"2026-10-09T23:06:12","modified_gmt":"2026-10-09T21:06:12","slug":"cookie-lebensdauer-die-drei-browsergrenzen-und-wie-die-art-des-setzens","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-marketing-de\/cookie-lebensdauer-die-drei-browsergrenzen-und-wie-die-art-des-setzens\/","title":{"rendered":"Cookie-Lebensdauer: Die drei Browsergrenzen und wie die Art des Setzens sie ver\u00e4ndert"},"content":{"rendered":"

Ein Cookie-Header ist eine Bitte und keine Anweisung. Max-Age=63072000<\/code> bittet um zwei Jahre, und was der Browser gew\u00e4hrt, h\u00e4ngt an etwas, das im Header gar nicht vorkommt: daran, wie das Cookie zustande kam. Dieselbe Zeile ergibt im einen Fall zwei Jahre und im anderen sieben Tage, und nichts in der Antwort sagt, welcher Fall vorliegt.<\/p>\n

Der Unterschied reicht \u00fcber Ordnungsliebe hinaus. Ein wiederkehrender Besucher kehrt nur so lange wieder, wie das Cookie besteht, das ihn erkennt; ist es weg, z\u00e4hlt der Besucher als neu, und jedes Fenster, das l\u00e4nger ist als die Lebensdauer des Cookies, rechnet mit Daten, die es nicht mehr gibt.<\/p>\n

\n\"Ein
Derselbe Header, drei Ergebnisse. Welches gilt, entscheidet sich, bevor der Header geschrieben wird.<\/figcaption><\/figure>\n

Die drei Kappungen<\/h2>\n

Safari k\u00fcrzt jeden \u00fcber document.cookie<\/code> geschriebenen Cookie auf sieben Tage. Das ist die Regel mit der gr\u00f6\u00dften praktischen Wirkung, denn die meisten Mess-Cookies entstehen genau so – durch ein Tag, das in der Seite l\u00e4uft.<\/p>\n

Dieselben sieben Tage wendet Safari auf Cookies an, die in einer HTTP-Antwort von einem Host kommen, der \u00fcber einen CNAME anderswo aufl\u00f6st. Gemeint ist damit die Anordnung, bei der eine Subdomain der Seite auf einen Messdienstleister zeigt; die Wirkung ist, dass ein korrekt gesetztes Erstanbieter-Cookie wie eines von Dritten behandelt wird.<\/p>\n

Chrome und Firefox kappen bei 400 Tagen. Diese Zahl tut selten weh – sie liegt \u00fcber jedem vern\u00fcnftigen Messfenster – beendet aber stillschweigend das Zwei-Jahres-Cookie, das seit 2018 in der Tag-Vorlage steht.<\/p>\n

Warum der Weg entscheidet und nicht das Attribut<\/h2>\n

Zwei Cookies mit gleichen Attributen k\u00f6nnen verschiedene Laufzeiten haben, und der einzige Unterschied ist, wer sie geschrieben hat. Ein Cookie, das ein Skript in der Seite setzt, wird gek\u00fcrzt; dasselbe Cookie in der Antwort des eigenen Servers nicht.<\/p>\n

Deshalb ist es die wirksamste einzelne \u00c4nderung, das Cookie in die Antwort zu verlegen: sie kostet einen Endpunkt auf der eigenen Domain und macht den Unterschied zwischen einer Woche Wiedererkennung und einem Jahr. Das Tag liest das Cookie dann, statt ihn zu schreiben.<\/p>\n

Der Umzug hat eine zweite Wirkung, die der Erw\u00e4hnung wert ist: ein in der Antwort geschriebenes Cookie kann HttpOnly<\/code> tragen, und ein Cookie mit HttpOnly<\/code> liest kein Skript der Seite – auch keines, das dort niemand absichtlich eingebaut hat.<\/p>\n

Was ein CNAME daran \u00e4ndert<\/h2>\n

Eine Subdomain, die auf einen Dienstleister zeigt, sieht in der Adresszeile nach Erstanbieter aus. Der Browser kann jedoch die DNS-Aufl\u00f6sungskette pr\u00fcfen und erkennen, dass der Host anderswo endet. Diese Information nutzt die Abwehr gegen CNAME-Cloaking.<\/p>\n

Die Folge geh\u00f6rt eingeplant statt entdeckt: eine Anordnung, die gebaut wurde, um Drittanbieter-Beschr\u00e4nkungen zu entgehen, erbt in Safari die Kappung auf sieben Tage und gewinnt daf\u00fcr eine Subdomain, deren Ausfall die ganze Messung mitnimmt. L\u00e4uft der Endpunkt auf eigener Infrastruktur, trifft weder das eine noch das andere zu.<\/p>\n

Die Attribute, an denen ein Cookie scheitert<\/h2>\n\n\n\n\n\n\n\n\n\n
So geschrieben<\/th>\nWas geschieht<\/th>\n<\/tr>\n<\/thead>\n
SameSite=None<\/code> ohne Secure<\/code><\/td>\nWird von jedem aktuellen Browser rundweg abgelehnt – das Cookie wird nie gespeichert.<\/td>\n<\/tr>\n
Gar kein SameSite<\/code><\/td>\nGilt als Lax<\/code>, das Cookie fehlt damit bei Anfragen von fremden Seiten.<\/td>\n<\/tr>\n
__Host-<\/code> mit Domain<\/code><\/td>\nAbgelehnt: das Pr\u00e4fix verbietet Domain und verlangt Secure und Path=\/.<\/td>\n<\/tr>\n
Name und Wert \u00fcber 4096 Byte<\/td>\nKommentarlos verworfen – so h\u00f6rt ein gewachsener Einwilligungsstring auf anzukommen.<\/td>\n<\/tr>\n
Max-Age<\/code> und Expires<\/code> zusammen<\/td>\nMax-Age gewinnt. Expires ist nur f\u00fcr Browser da, die niemand mehr hat.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Alle scheitern auf dieselbe Weise: die Antwort ist in Ordnung, das Cookie ist hinterher schlicht nicht da. Die einzige verl\u00e4ssliche Pr\u00fcfung ist der Blick auf das, was der Browser gespeichert hat, und nicht auf das, was gesendet wurde.<\/p>\n

Was daraus f\u00fcr die Messung folgt<\/h2>\n

Ein Sieben-Tage-Cookie macht aus einem Besucher, der nach acht Tagen wiederkommt, einen neuen. Im Bericht zeigt sich das als Anteil wiederkehrender Besucher, der unter Safari niedriger liegt als \u00fcberall sonst, und als Conversion-Pfade, die k\u00fcrzer sind als der Verkaufszyklus – nicht weil die Reise kurz war, sondern weil ihr fr\u00fcherer Teil nicht mehr daran h\u00e4ngt.<\/p>\n

Wo sich das Cookie nicht verl\u00e4ngern l\u00e4sst, ist die ehrliche Antwort, das Fenster zu verk\u00fcrzen, statt weiter eines auszuweisen, das die Daten nicht tragen. Ein drei\u00dfigt\u00e4giges Attributionsfenster \u00fcber einem Sieben-Tage-Cookie beschreibt einen Zeitraum, an den der Browser keine Erinnerung hat, und jede daraus abgeleitete Zahl erbt diese L\u00fccke.<\/p>\n

\n

Fragen und Antworten<\/h2>\n

Verl\u00e4ngert sich ein per Skript geschriebenes Cookie, wenn das Tag es bei jedem Besuch neu schreibt?<\/h3>\n

Ja, aber nur bis zur ersten l\u00e4ngeren Pause. Jedes Schreiben \u00fcber document.cookie setzt in Safari eine neue Frist von sieben Tagen, gerechnet ab diesem Zeitpunkt. Wer innerhalb von sieben Tagen wiederkommt, bleibt deshalb erkannt, beliebig oft hintereinander; wer acht Tage wegbleibt, kommt als neuer Besucher zur\u00fcck, wie im Artikel beschrieben.<\/p>\n

Gen\u00fcgt es, den eigenen Messendpunkt per A-Eintrag statt per CNAME an die Subdomain zu binden?<\/h3>\n

Nicht zwingend. Seit Safari 16.4 pr\u00fcft WebKit neben der CNAME-Kette auch die IP-Adresse: Liegt der Server, der auf der Subdomain antwortet, in einem deutlich anderen Adressbereich als die Seite selbst, k\u00fcrzt Safari die Cookies aus dessen Antworten ebenfalls auf sieben Tage. Ein A-Eintrag, der auf einen Server bei einem Cloud-Anbieter zeigt, w\u00e4hrend die Hauptseite ganz woanders liegt, entgeht der CNAME-Regel also und trifft trotzdem auf dieselbe Kappung.<\/p>\n

\u201eEigene Infrastruktur\u201c im Sinne des Artikels hei\u00dft deshalb: Der Endpunkt antwortet aus demselben Adressbereich wie die Seite, etwa weil beide hinter demselben Server oder demselben vorgeschalteten Netz liegen, oder er l\u00e4uft unter einem Pfad der Hauptdomain, der die Anfrage intern weiterreicht. Ob das gelungen ist, zeigt dieselbe Probe wie bei den Attributen: das in Safari gespeicherte Ablaufdatum, nicht der gesendete Header.<\/p>\n

Was \u00e4ndert der Umzug des Cookies in die Serverantwort an Einwilligung und Widerruf?<\/h3>\n

An der Einwilligung nichts. Ob ein Cookie eine Einwilligung braucht, entscheidet sein Zweck und nicht der Weg, auf dem es entsteht; auf dem Ger\u00e4t gespeichert und von dort gelesen wird es so oder so. Ein Mess-Cookie aus der Serverantwort braucht also dieselbe Einwilligung wie vorher, und der Endpunkt muss den Einwilligungsstand kennen, bevor er es setzt. Die l\u00e4ngere Laufzeit geh\u00f6rt au\u00dferdem dorthin, wo die Speicherdauer genannt wird, ins Einwilligungsbanner und in die Datenschutzerkl\u00e4rung.<\/p>\n

Beim Widerruf \u00e4ndert sich dagegen etwas Handfestes. Ein Cookie mit HttpOnly l\u00e4sst sich von keinem Skript der Seite l\u00f6schen, auch nicht vom Einwilligungsbanner. Der Widerruf muss deshalb eine Anfrage an den eigenen Server ausl\u00f6sen, der das Cookie mit einer Antwort wie Max-Age=0<\/code> entfernt; sonst bleibt es nach dem Widerruf bis zum Ende seiner Laufzeit bestehen, und die kann jetzt ein Jahr betragen.<\/p>\n

Wie l\u00e4sst sich pr\u00fcfen, welche Laufzeit der Browser einem Cookie tats\u00e4chlich gew\u00e4hrt hat?<\/h3>\n

Durch den Vergleich zweier Stellen in den Entwicklerwerkzeugen, und zwar in jedem Browser einzeln:<\/p>\n

    \n
  1. Der Set-Cookie-Header im Netzwerkbereich zeigt die Bitte, also Max-Age oder Expires, wie der Server sie gesendet hat.<\/li>\n
  2. Der Speicherbereich zeigt die Gew\u00e4hrung: das Ablaufdatum, das der Browser tats\u00e4chlich abgelegt hat. Bei einem per Skript geschriebenen Cookie, das um zwei Jahre bittet, steht dort in Safari ein Datum sieben Tage sp\u00e4ter, in Chrome und Firefox eines 400 Tage sp\u00e4ter.<\/li>\n
  3. Fehlt das Cookie im Speicher ganz, ist es an einem der Attribute aus der Tabelle gescheitert. Chrome markiert abgelehnte Cookies in den Details der jeweiligen Anfrage und nennt den Grund.<\/li>\n<\/ol>\n

    Die Sieben-Tage-Regeln stammen aus WebKit und lassen sich nur dort messen, also in Safari; ein Test in Chrome auf dem Desktop zeigt h\u00f6chstens die 400 Tage. Auch ein Blick in den Bericht ersetzt die Probe nicht: Der niedrigere Anteil wiederkehrender Besucher unter Safari ist die Folge, nicht der Nachweis der Ursache.<\/p>\n<\/div>\n

    \n

    Quellen<\/h2>\n