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 geregelt¹.

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ösen². Drei Jahrzehnte später ist das zugrunde liegende Protokoll im Wesentlichen unverändert. Die formale Spezifikation ist IETF RFC 6265¹, mit einer aktiven Revision in IETF-Entwürfen³, 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 6265¹ und seiner bis-Revision³:

• Name und Wert — das einzige Pflichtpaar. ASCII-Text. Zusammen müssen sie in rund 4 KB passen⁴.
• Domain — Standard ist der Host, der Set-Cookie gesendet hat. Domain=example.com zu setzen, lässt das Cookie für example.com und alle Subdomains gelten.
• Path — Standard ist das Verzeichnis des Anfragepfads. Path=/account zu setzen, beschränkt das Cookie auf URLs unter /account.
• Expires / Max-Age — Datum oder Dauer. Beide wegzulassen, macht das Cookie zu einem Sitzungs-Cookie (gelöscht, wenn die Browser-Sitzung endet). Max-Age=0 löscht das Cookie sofort.
• Secure — gesetzt, sendet der Browser das Cookie nur über HTTPS. Reine HTTP-Anfragen sehen es nicht.
• HttpOnly — gesetzt, kann JavaScript in der Seite das Cookie nicht über document.cookie erreichen. Die primäre Verteidigung gegen Session-Cookie-Diebstahl per XSS.
• SameSite — Strict / Lax / None. Steuert das Verhalten bei websiteübergreifenden Anfragen (unten behandelt).
• Priority (Chrome-spezifische Erweiterung) — Low / Medium / High. Gibt dem Browser einen Hinweis, welche Cookies zuerst zu verdrängen sind, wenn der Cookie-Behälter pro Domain voll ist.

Cookie-Typen

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:

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

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:

• Secure verteidigt gegen passives Netzwerk-Schnüffeln. Der Browser weigert sich, das Cookie über reines HTTP zu senden. Erforderlich für jedes Cookie, das Sitzungszustand hält, da Session-Diebstahl über ein offenes WLAN sonst trivial ist.
• HttpOnly verteidigt gegen XSS-getriebenen Session-Diebstahl. JavaScript, das über eine Cross-Site-Scripting-Schwachstelle in die Seite eingeschleust wird, kann ein HttpOnly-Cookie nicht über document.cookie lesen. Der Server sieht es weiterhin; das Skript des Angreifers nicht.
• SameSite verteidigt gegen CSRF und websiteübergreifendes Tracking. Drei Werte:
  • SameSite=Strict — das Cookie wird nur bei gleicher-Website-Anfragen gesendet. Maximaler Schutz; manchmal unbequem (ein Nutzer, der von einer anderen Website zu deiner Domain klickt, erscheint bei der ersten Anfrage abgemeldet).
  • SameSite=Lax — das Cookie wird bei gleicher-Website-Anfragen plus websiteübergreifenden GET-Navigationen oberster Ebene (Linkklicks) gesendet. Die moderne Chrome-Voreinstellung seit 2020⁷.
  • SameSite=None — das Cookie wird bei jeder websiteübergreifenden Anfrage gesendet. Erforderlich für legitime Drittanbieter-Cookies (Single Sign-On, eingebettete Bezahl-Widgets). Muss mit Secure gepaart werden.

Die web.dev-Anleitung von Google ist bei der Prioritätenreihenfolge eindeutig⁷: “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:

• Safari — Drittanbieter-Cookies sind standardmäßig blockiert, seit die Intelligent Tracking Prevention (ITP) in Safari 11 (2017) erschien, mit sukzessiven Verschärfungen.
• Firefox — Drittanbieter-Cookies sind seit 2022 unter Total Cookie Protection (TCP) standardmäßig partitioniert, was websiteübergreifendes Tracking effektiv beseitigt.
• Chrome — nach mehreren Verschiebungen der vollständigen Drittanbieter-Cookie-Abschaltung⁵ legte sich auf einen Nutzerwahl-Ansatz fest, mit den Privacy-Sandbox-APIs als vorgeschlagenem Ersatz für Werbe-Targeting, Attribution und Betrugsprävention.

Für legitime websiteübergreifende Anwendungsfälle (föderiertes Login, eingebettete Checkout-iFrames) ist die moderne Alternative CHIPS — Cookies Having Independent Partitioned State⁸. 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:

• “Cookies sind Viren” — falsch. Ein Cookie ist ein passiver Texteintrag. Es kann keine Software installieren, keinen Code ausführen und keine Dateien außerhalb des Cookie-Speichers des Browsers erreichen.
• “Cookies speichern dein Passwort” — fast immer falsch. Ein Login-Cookie hält eine Session-ID, kein Passwort. Das Passwort wird einmal an den Server gesendet, gehasht, und der Server gibt ein Session-ID-Cookie zurück. Das Passwort selbst ist nicht im Cookie.
• “Cookies zu deaktivieren macht dich anonym” — falsch. Browser sind über viele andere Kanäle fingerprintbar (User-Agent, Bildschirmauflösung, Schriftarten, WebGL-Hashes, IP-Adresse), die nicht von Cookies abhängen.
• “Alle Cookies tracken dich über Websites hinweg” — falsch. Erstanbieter-Cookies, die von der Website gesetzt werden, die du besuchst, sehen dich nicht auf anderen Websites. Websiteübergreifendes Tracking ist speziell ein Drittanbieter-Cookie-Anliegen.
• “Cookies sind unter der DSGVO illegal” — falsch. Cookies sind legal. Was die DSGVO (und die ePrivacy-Richtlinie) regulieren, ist die Einwilligungs-Anforderung für nicht-essenzielle Cookies. Unbedingt erforderliche Cookies brauchen keine Einwilligung.
• “Cookies zu löschen behebt jedes Browser-Problem” — teilweise wahr. Cookies zu löschen setzt Sitzungs- und Präferenzzustand zurück. Es behebt keine zwischengespeicherten Ressourcen, keine Service-Worker-Bugs und keine Erweiterungskonflikte.

Siehe auch

• Wie man Cookies in Chrome löscht
• Cookies löschen, aber angemeldet bleiben
• Wie man Cookies in Chrome bearbeitet
• Wie man Cookies als JSON exportiert
• CookieVault Editor — der quelloffene Manifest-V3-Cookie-Manager
• CookieVault Guardian — Cookies beim Tab-Schließen automatisch löschen