Was ist ein Cookie? Browser-Cookies erklärt

TL;DR: Ein Cookie ist ein kleines Datenstück — typischerweise ein paar hundert Bytes —, das eine Website in deinem Browser speichert, um Informationen zwischen Anfragen zu merken. Cookies treiben Logins, Warenkörbe und Analytics an; sie ermöglichten auch die Ära des websiteübergreifenden Trackings, die Browser jetzt zurückfahren.

Ein Cookie ist ein Name-Wert-Texteintrag, den eine Website über den HTTP-Antwort-Header Set-Cookie in deinem Browser setzt und den der Browser über den Anfrage-Header Cookie automatisch an nachfolgende Anfragen an dieselbe Domain anhängt. Cookies sind der ursprüngliche Mechanismus für Zustand auf einem ansonsten zustandslosen HTTP-Web — sie sind älter als localStorage, IndexedDB, Service Worker und jede moderne Client-Speicher-Alternative. Jedes Cookie, dem du je begegnet bist, von “angemeldet bleiben” bis zum EU-Einwilligungsbanner, das danach fragt, wird von diesem einen kleinen Protokoll geregelt1.

Wie Cookies funktionieren

Kurz gesagt: Cookies sind eine dünne Schicht über HTTP. Der Server setzt eines mit einem Set-Cookie: name=value-Antwort-Header; der Browser speichert es in einem Cookie-Behälter pro Domain; bei jeder folgenden passenden Anfrage sendet der Browser Cookie: name=value zurück. Es gibt keinen clientseitigen Handshake — der Browser befolgt die Direktiven des Servers innerhalb der Grenzen von RFC 6265.

Der Cookie-Mechanismus wird weithin Lou Montulli zugeschrieben, einem Netscape-Ingenieur, der ihn 1994 einführte, um “merke den Warenkorb zwischen Seiten” für den E-Commerce-Kunden MCI Net zu lösen2. Drei Jahrzehnte später ist das zugrunde liegende Protokoll im Wesentlichen unverändert. Die formale Spezifikation ist IETF RFC 62651, mit einer aktiven Revision in IETF-Entwürfen3, die die Sicherheits- und Datenschutzgrenzen verschärft.

Ein minimaler Cookie-Austausch sieht so aus:

# Server-Antwort
HTTP/1.1 200 OK
Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

# Folgende Client-Anfrage an dieselbe Website
GET /account HTTP/1.1
Cookie: sid=abc123

Der Browser interpretiert den Wert abc123 nicht — er ist für den Browser undurchsichtig. Der Server interpretiert ihn (typischerweise als Datenbank-Session-Schlüssel). Die Aufgabe des Browsers ist es, anhand der Attribute Domain, Path, Secure, SameSite und Ablauf des Cookies zu entscheiden, welche Cookies an jede Anfrage angehängt werden.

Kernpunkt: Ein Cookie wird vom Server gesetzt, vom Browser gespeichert und vom Server bei jeder folgenden passenden Anfrage gelesen. Der Browser ist der Kurier, nicht der Verfasser.

Anatomie eines Cookies

Kurz gesagt: Ein Cookie hat einen Pflichtteil (name=value) und sieben Attribute, die der Server setzen kann: Domain, Path, Expires, Max-Age, Secure, HttpOnly und SameSite. Jedes Attribut grenzt ein oder schränkt ein, wann der Browser das Cookie zurücksendet.

Der vollständige Attributsatz, definiert in RFC 62651 und seiner bis-Revision3:

Kurz gesagt: Cookies werden entlang zweier orthogonaler Achsen klassifiziert — Lebensdauer (Sitzung vs. persistent) und Herkunft (Erstanbieter vs. Drittanbieter). Ein einzelnes Cookie hat immer einen Wert auf jeder Achse. Datenschutzvorschriften und Browser-Einstellungen legen dann ein nutzungsbasiertes Kategoriensystem darüber (unbedingt erforderlich / funktional / Analytics / Werbung), das du auf Einwilligungsbannern siehst.

Sechs gängige Kategorien, über die Nutzer und Regulierer sprechen, auf das zugrunde liegende Protokoll abgebildet:

KategorieLebensdauerHerkunftTypische NutzungStandard-Browser-Richtlinie (2026)
Sitzungs-CookieSitzungErstanbieterLogin-Sitzung, aktueller WarenkorbStandardmäßig erlaubt
Persistent ErstanbieterPersistentErstanbieter”Angemeldet bleiben”, SpracheinstellungStandardmäßig erlaubt
Unbedingt erforderlichBeidesErstanbieterAuth, BetrugspräventionKeine Einwilligung nötig (DSGVO)
Funktional / PräferenzPersistentErstanbieterUI-Theme, SchriftgrößeEinwilligung empfohlen (DSGVO)
Analytics ErstanbieterPersistentErstanbieterErstanbieter-AnalyticsEinwilligung in der EU erforderlich
Drittanbieter-WerbungPersistentDrittanbieterWerbe-Targeting, Retargeting, Cross-Site-IDsBlockiert in Safari / Firefox; eingeschränkt in Chrome5

Das Information Commissioner’s Office (UK) fasst die Unterscheidung knapp zusammen6:

Unbedingt erforderliche Cookies sind solche, die wesentlich sind, um einen vom Nutzer angeforderten Online-Dienst bereitzustellen. Die meisten anderen Cookies erfordern eine informierte Einwilligung, bevor sie gesetzt werden.

Wofür Cookies verwendet werden

Kurz gesagt: Auf Protokollebene ist ein Cookie generischer Name-Wert-Speicher. In der Praxis nutzt das Web Cookies für sechs verschiedene Aufgaben, in etwa absteigender Reihenfolge ihrer Bedeutung für die Nutzererfahrung.

Die sechs dominierenden Cookie-Anwendungsfälle im modernen Web:

  1. Authentifizierung und Session-Management — ein Session-ID-Cookie, das dem Server sagt, zu welchem angemeldeten Nutzer eine Anfrage gehört. Fast immer HttpOnly, Secure, SameSite=Lax oder Strict.
  2. CSRF-Schutz-Token — ein zufälliger Anti-Fälschungs-Wert, den der Server bei zustandsändernden Anfragen prüft. Meist mit einem versteckten Formularfeld gepaart.
  3. Warenkorb und unfertige Arbeit — Bewahren von Warenkorbinhalten und Formularentwürfen über Seitenladevorgänge hinweg. Oft eine einzelne ID, die auf serverseitigen Zustand zeigt.
  4. Nutzereinstellungen — Sprache, Theme, Layout-Dichte, Barrierefreiheits-Einstellungen. Kleine persistente Cookies mit Max-Age von Monaten bis Jahren.
  5. Erstanbieter-Analytics — Besucheridentifikation und Sitzungs-Timing für Produkte wie Plausible, Fathom oder selbst gehostetes PostHog (wenn cookie-basiert konfiguriert).
  6. Werbung und websiteübergreifendes Tracking — Drittanbieter-Cookies, gesetzt von Werbenetzwerken, Retargetern und Analytics-Plattformen, die denselben Nutzer über mehrere Websites hinweg identifizieren müssen. Das ist die Kategorie, die Browser aktiv zurückfahren.

Für Entwickler ist die praktische Folge, dass die meisten Cookies, die du setzt, Erstanbieter sein sollten, auf die aktuelle Website beschränkt, als HttpOnly und Secure markiert und mit SameSite=Lax versehen, es sei denn, du hast einen bestimmten websiteübergreifenden Ablauf, der None braucht.

SameSite, HttpOnly, Secure — die drei Sicherheitsattribute

Kurz gesagt: Drei Cookie-Attribute — SameSite, HttpOnly und Secure — verteidigen gegen drei verschiedene Angriffsklassen. Alle drei korrekt zu setzen, ist die wirkungsvollste einzelne Cookie-Sicherheitsverbesserung, die ein Server vornehmen kann.

Diese drei Attribute bilden die moderne Cookie-Sicherheitsbasis. Jedes verteidigt gegen eine bestimmte Angriffsklasse:

Die web.dev-Anleitung von Google ist bei der Prioritätenreihenfolge eindeutig7: “Wenn du heute nur eine Sache tust, setze SameSite=Lax auf jedes Sitzungs-Cookie.”

Erstanbieter- vs. Drittanbieter-Cookies und die Abschaltungsgeschichte

Kurz gesagt: Ein Erstanbieter-Cookie wird von der Website in der URL-Leiste gesetzt; ein Drittanbieter-Cookie wird von einer anderen Domain gesetzt, deren Code auf dieser Website läuft. Drittanbieter-Cookies bauten die moderne Werbe-Tracking-Ökonomie auf, und moderne Browser schränken sie systematisch ein oder beseitigen sie.

Das Zurückfahren von Drittanbieter-Cookies ist die folgenreichste Änderung am Cookie-Ökosystem seit der Schaffung des Protokolls. Status nach Browser ab Mitte 2026:

Für legitime websiteübergreifende Anwendungsfälle (föderiertes Login, eingebettete Checkout-iFrames) ist die moderne Alternative CHIPS — Cookies Having Independent Partitioned State8. Ein Cookie mit dem Attribut Partitioned wird in einem separaten Behälter pro oberster Website gespeichert, sodass derselbe iFrame, geladen unter zwei verschiedenen Elternseiten, nicht dasselbe Cookie lesen kann. CHIPS bewahrt den legitimen Anwendungsfall “merke Einstellungen innerhalb dieses Widgets”, während es den websiteübergreifenden Identifikator-Fluss unterbricht.

Wenn du heute einen Dienst betreibst, der von Drittanbieter-Cookies abhängt, ist die unmittelbare Arbeit, deine Cookies daraufhin zu prüfen, welche websiteübergreifende Sichtbarkeit brauchen (nutze CHIPS) und welche von vornherein Tracking waren (auf Privacy Sandbox oder Erstanbieter-Daten neu aufbauen).

Wie du Cookies anzeigst, bearbeitest und löschst

Kurz gesagt: Jeder moderne Browser lässt dich Cookies über Einstellungen oder DevTools anzeigen. Für wiederholbare Abläufe — Session-Bugs debuggen, Cookies als Test-Fixtures exportieren, prüfen, was eine Website gespeichert hat — ist eine Manifest-V3-Erweiterung wie CookieVault Editor das Standardwerkzeug. Der achtstufige Inspektions-Workflow unten funktioniert in jedem Chromium-Browser.

Achtstufige Schnellreferenz zum Anzeigen und Bearbeiten von Cookies in Chrome (Edge, Brave, Opera, Vivaldi, Arc funktionieren identisch; Firefox ist ähnlich mit einem anderen Menü-Layout):

  1. Öffne die Zielwebsite in einem Tab.
  2. Drücke F12, um die DevTools zu öffnen.
  3. Klicke auf den Tab Application.
  4. Klicke in der linken Seitenleiste unter Storage auf Cookies.
  5. Klicke auf die Domain, um alle Cookies im Geltungsbereich zu sehen.
  6. Doppelklicke auf eine Zelle (Value, Expires, SameSite usw.), um sie direkt zu bearbeiten.
  7. Drücke Enter, um die Änderung zu übernehmen; der Browser wendet sie sofort an.
  8. Lade die Seite neu, um das geänderte Cookie bei der nächsten Anfrage zu senden.

Zum Löschen von Cookies in großen Mengen behandelt der Leitfaden zum Cookie-Löschen in Chrome drei Methoden. Um Logins zu behalten und dabei Tracker zu entfernen, siehe Cookies löschen, aber angemeldet bleiben. Für wiederholbare Ein-Klick-Bearbeitungen über viele Websites hinweg ist CookieVault Editor das quelloffene Manifest-V3-Werkzeug, das wir pflegen.

Häufige Missverständnisse über Cookies

Eine kurze Klarstellung von Aussagen, die du im Internet gesehen haben magst und die nicht stimmen:

Siehe auch

Footnotes

  1. Die aktuelle IETF-Spezifikation ist RFC 6265 — “HTTP State Management Mechanism”, verfügbar unter https://datatracker.ietf.org/doc/html/rfc6265. Dieses Dokument definiert die Header Set-Cookie und Cookie, die Semantik der Cookie-Attribute, das Speichermodell und die Cookie-Abgleichsregeln. ↩ ↩2 ↩3

  2. Die HTTP-Cookies-Referenz des Mozilla Developer Network unter https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies fasst den modernen Cookie-Attributsatz und die browserseitigen Verarbeitungsregeln zusammen. Die Ursprungsgeschichte von 1994 wird über Web-Geschichtsquellen hinweg breit zitiert und geht auf Lou Montullis Arbeit bei Netscape an einer “Einkaufskorb”-Funktion zurück. ↩

  3. Die aktive Revision der Cookie-Spezifikation ist “RFC 6265bis” — formal draft-ietf-httpbis-rfc6265bis — veröffentlicht in der IETF-HTTP-Arbeitsgruppe unter https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/. Sie verschärft Präfix-Regeln (__Host-, __Secure-), formalisiert SameSite und verfeinert die Partitionierungs-Semantik. ↩ ↩2

  4. Die Werte 4 KB pro Cookie und 50 Cookies pro Domain sind Empfehlungen aus RFC 6265 §6.1. Reale Browser-Limits sind etwa doppelt so hoch wie das empfohlene Minimum, variieren aber je nach Browser; die chrome.cookies-API-Referenz des Chrome-Teams unter https://developer.chrome.com/docs/extensions/reference/api/cookies dokumentiert die praktischen Chrome-Limits. ↩

  5. Chromes Position zu Drittanbieter-Cookies hat sich mehrfach verschoben. Der aktuelle Ansatz ist unter Privacy Sandbox unter https://developer.chrome.com/docs/privacy-sandbox/ dokumentiert. Statusseiten und einzelne API-Dokumentationen unter diesem Stamm verfolgen laufende Änderungen. ↩ ↩2

  6. Das UK Information Commissioner’s Office (ICO) veröffentlicht praktische Hinweise zu Cookies und Einwilligung unter den Privacy and Electronic Communications Regulations (PECR). Das ICO hat diese Hinweisseite mehrfach umstrukturiert und die URL ist instabil; suche nach “ICO PECR cookies guidance” oder beginne bei https://ico.org.uk und navigiere zu “For organisations → Online tracking”. Die in der obigen Tabellen-Anmerkung sinngemäß übernommene Definition “unbedingt erforderlich” folgt der ICO-Formulierung. ↩

  7. Googles web.dev-Einführung “SameSite cookies explained” unter https://web.dev/articles/samesite-cookies-explained ist die kanonische, an Praktiker gerichtete Referenz für SameSite-Voreinstellungen und die Chrome-Rollout-Geschichte. ↩ ↩2

  8. Die CHIPS-Spezifikation — “Cookies Having Independent Partitioned State” — ist unter https://developer.chrome.com/docs/privacy-sandbox/chips dokumentiert. CHIPS erlaubt einem websiteübergreifenden Cookie, sich für die Partitionierung pro oberster Website anzumelden, sodass es die Drittanbieter-Cookie-Blockierung überlebt, ohne websiteübergreifendes Tracking zu ermöglichen. ↩