Cookies und LocalStorage

Die Speicher-Klassen im Überblick

Moderne Browser bieten mehrere Mechanismen, mit denen eine Webseite Daten auf deinem Gerät speichern kann:

Der wichtigste konzeptionelle Unterschied: Cookies wandern automatisch mit jeder HTTP-Anfrage an den Server zurück. Die anderen Speicher-Klassen bleiben rein im Browser — wenn die Site nicht aktiv JavaScript ausführt, das den Wert ausliest und an einen Server schickt, sieht der Server sie nicht.

Daraus folgt: für klassisches Session-Management (eingeloggt bleiben) sind Cookies geeignet — der Server bekommt sie automatisch. Für lokales App-Verhalten (Einstellungen, Cache) sind LocalStorage und IndexedDB geeignet — die Daten bleiben da, ohne den Server zu belasten.

First-Party vs. Third-Party

Ein zentrales Konzept im Tracking-Diskurs:

• First-Party — das Speicherobjekt gehört zur Domain, deren Seite du gerade direkt besuchst. Du bist auf zeit.de, ein Cookie von zeit.de ist First-Party.
• Third-Party — das Speicherobjekt gehört zu einer anderen Domain, deren Code auf der besuchten Seite eingebettet ist. Du bist auf zeit.de, ein Cookie von googletagmanager.com ist Third-Party.

Die Third-Party-Variante ist der traditionelle Tracking-Hebel: ein Tracker (z. B. Facebook Pixel) wird auf vielen Webseiten eingebettet. Bei jedem Aufruf liest oder setzt er ein eigenes Cookie. Über mehrere Webseiten hinweg entsteht ein Profil: Person X hat die Banking-Seite, dann den Möbelladen, dann die Reise-Seite besucht.

Wo die Browser heute stehen:

• Safari: Third-Party-Cookies seit 2020 standardmäßig blockiert (Intelligent Tracking Prevention).
• Firefox: seit 2019 mit „Enhanced Tracking Protection" Third-Party-Cookies bekannter Tracker standardmäßig blockiert. Im strikten Modus alle.
• Chrome: seit 2024 schrittweise Blockade in Vorbereitung. Stand Mitte 2026 noch nicht universell, aber stark eingeschränkt für viele Domain-Klassen.
• Edge: folgt Chromium.

Was bleibt: First-Party-Cookies. Auf einer einzelnen Seite verfolgst du nichts gegen, aber wenn dieselbe Person sich auf mehreren Sites mit derselben Mail-Adresse oder Phone-Number anmeldet, lässt sich auch über First-Party-Daten verbinden.

Storage Partitioning: die fundamentale Änderung

Während Third-Party-Cookies langsam verschwinden, hatten Tracker eine Ausweich-Strategie: LocalStorage in Third-Party-iframes. Wenn eine Tracking-Domain in einem iframe geladen wird, kann sie dort LocalStorage nutzen — und der Wert wurde traditionell über alle Webseiten hinweg geteilt, auf denen dieselbe Tracking-Domain als iframe eingebettet war.

Storage Partitioning ändert das fundamental. Seit Firefox 103 (2022), Safari 16 (2022) und Chrome 115 (2023) gilt:

Jeder Speicher — Cookies, LocalStorage, IndexedDB, Cache, ServiceWorker — eines Third-Party-Iframes wird partitioniert nach dem Top-Level-Document.

Konkret: Ein Tracking-Iframe von tracker.example auf zeit.de sieht einen anderen LocalStorage als derselbe Tracking-Iframe von tracker.example auf spiegel.de. Die Tracking-Identität, die der Iframe auf der Zeit-Seite anlegt, ist auf der Spiegel-Seite nicht sichtbar.

Damit ist ein Großteil des klassischen Cross-Site-Trackings durch eingebettete Iframes erledigt. Die Tracker müssen jetzt entweder auf Server-Side-Linking (Mail-Hashes) oder auf Fingerprinting (siehe nächster Artikel) ausweichen.

Was Partitioning NICHT bricht:

• Wenn du dich auf mehreren Seiten mit derselben Mail-Adresse anmeldest, lassen sich Profile weiter zusammenführen.
• Wenn Werbenetzwerke serverseitige Identity-Resolution (LiveRamp, ID5) nutzen, läuft das Tracking weiter — die Browser-Schicht ist nur eine von mehreren.
• Werbe-IDs auf Mobile sind ein eigenständiger Mechanismus außerhalb des Browser-Partitioning.

Cookie-Banner: was rechtlich erforderlich ist

Seit TTDSG (Deutschland, 2021) und vergleichbaren ePrivacy-Umsetzungen in anderen EU-Staaten gilt: das Setzen von Cookies — und das Auslesen aus dem Browser-Speicher — braucht vorherige Einwilligung, außer für „technisch zwingend erforderliche" Speicher (Warenkorb, Session-Cookie für Login, Sprach-Wahl).

Was eine konforme Banner-Lösung ausmacht (laut DSK-Orientierungshilfe und mehreren EuGH-/EDSA-Entscheidungen):

• Gleichwertige Buttons. „Akzeptieren" und „Ablehnen" gleich groß, gleiche Farbe, gleich präsent.
• Keine Pre-Selection. Alle nicht-zwingenden Cookies sind vor der Auswahl AUS.
• Keine Dark Patterns. „Ablehnen" darf nicht versteckt sein („Mehr Optionen → Drei-Klicks zu …").
• Granularität. Nutzer kann pro Kategorie (oder pro Anbieter) entscheiden.
• Information. Klar dargestellt, welche Anbieter welche Daten zu welchem Zweck verarbeiten.

Was die Realität: eine sehr große Mehrheit der Banner ist nicht-konform. Aufsichts-Behörden mahnen langsam ab — CNIL (Frankreich) hat 2021/22 mehrere große Anbieter mit jeweils mehrstelligen Millionen-Bußgeldern belegt. Deutsche Verbraucherzentralen und Datenschützer-Initiativen wie noyb führen seit Jahren Sammelbeschwerden.

Pragmatischer Reflex für Nutzer:innen:

• „Alle ablehnen" wo erkennbar.
• Bei nicht erkennbarem „Ablehnen": „Einstellungen" öffnen, alle nicht-zwingenden Häkchen entfernen, speichern.
• Browser-Setting „Cookies beim Beenden löschen" (für nicht-essenzielle Sites) ergänzt das.
• Bei manchen Sites: Browser-Extensions wie Consent-O-Matic oder „I don't care about cookies" klicken automatisch das Ablehnen-Banner weg — Komfort, aber prüfen, ob die Extension vertrauenswürdig ist (Mozilla hat „I don't care about cookies" 2022 aufgekauft, Datenschützer waren skeptisch).

---

Cookie-Attribute, die Sicherheit bewirken

Für Verständnis-Zwecke (und für Web-Entwickler:innen): Cookies haben Attribute, die das Sicherheits-Verhalten steuern.

• Secure — Cookie wird nur über HTTPS gesendet, niemals über HTTP. Sollte heute auf jedem Cookie stehen.
• HttpOnly — Cookie ist nicht über document.cookie-JavaScript lesbar. Schützt vor XSS-getriebenem Cookie-Diebstahl. Pflicht für Session-Cookies.
• SameSite — kontrolliert, wann das Cookie bei Cross-Site-Anfragen mitgesendet wird. Werte:
  • Strict — Cookie geht nie bei Cross-Site-Requests mit. Stärkster Schutz, kann manche Workflows brechen.
  • Lax — Cookie geht bei Top-Level-Navigation (Link-Klick) mit, aber nicht bei eingebetteten Requests. Browser-Default seit 2020.
  • None — Cookie geht überall mit; muss mit Secure kombiniert sein.
• Domain — auf welchen Sub-Domains das Cookie gilt.
• Path — auf welchen Pfaden das Cookie gilt.
• __Host--Präfix / __Secure--Präfix — wenn der Cookie-Name so beginnt, erzwingt der Browser bestimmte Sicherheits-Eigenschaften (Cookie muss Secure sein, kein Domain-Attribut etc.).

Für Nutzer:innen relevant: dein Browser blockt Cookies mit verbotenen Kombinationen. Ein modernes SameSite=None-Cookie ohne Secure wird ignoriert. Ein Server, der das falsch setzt, hat schlicht keine Session bei dir.

Vertieft in cookie-flags-und-attribute (Entwickler-Sicht).

Browser-Settings, die wirklich helfen

Konkrete Schalter pro Browser:

Firefox

• Einstellungen → Datenschutz & Sicherheit → Browser-Datenschutz:
  • Streng (Strict) — blockt Cross-Site-Tracking, bekannte Tracker, Crypto-Mining, Fingerprinting.
  • Cookies und Webseiten-Daten beim Beenden von Firefox löschen — Häkchen setzen, Whitelist für wichtige Sites pflegen.
• Multi-Account-Containers installieren (siehe container-tabs-und-profile).

Safari

• Einstellungen → Datenschutz:
  • Cross-Site-Tracking verhindern an.
  • Alle Cookies blockieren ist deutlich strenger, bricht viele Sites — vor allem für Bank/Behörden problematisch.
  • IP-Adresse vor Trackern verbergen ist nützlich auf iCloud-Private-Relay-Setups.
• Verlauf → Verlauf und Website-Daten löschen alle paar Wochen.

Brave

• Brave Shields → Standard auf Aggressiv.
• Brave Cookie-Auto-Delete-Einstellungen pflegen.

Chrome / Edge

• Einstellungen → Datenschutz und Sicherheit → Cookies und andere Website-Daten:
  • Drittanbieter-Cookies blockieren an.
  • Beim Schließen aller Fenster Cookies und Website-Daten löschen (für nicht-essenzielle Sites).
• Schutz vor Tracking aktivieren (Edge: „Strikt"-Modus).

Plus über alle Browser hinweg: uBlock Origin installieren — siehe tracker-blocker.

Was du nicht löschen darfst — und was schon

Praktische Heuristik beim regelmäßigen Aufräumen:

Behalten:

• First-Party-Cookies aktiv genutzter Banken, Behörden-Portale, Webmail. Login-Sessions, „Vertrauter Browser"-Markierung für 2FA.
• LocalStorage von Tools, die du regelmäßig nutzt (CodeMirror-Setup, Anti-Tracking-Extension-Whitelists, Mail-Drafts).
• Cookies, die du als „immer behalten" konfiguriert hast im Browser.

Regelmäßig löschen:

• Cookies von Werbe-Domains — Google Tag Manager, Facebook Pixel, AppNexus, MediaMath, alles, was auf *-tracking, *-ads, *-analytics endet.
• Daten von Seiten, die du selten besuchst — alle paar Wochen automatisch über Browser-Setting.
• Cookies von Seiten, bei denen du dich nie aktiv anmeldest — Online-Shops mit Gast-Bestellungen, Nachrichten-Seiten, Such-Engines.

Sofort raus:

• Cookies von Phishing-Sites (falls aufgespürt nach versehentlichem Klick).
• Cookies nach kompromittierter Session (siehe Phishing-Reaktionsplan).
• Komplette Browser-Daten vor Geräte-Verkauf oder Reparatur.

Sehr einfache Routine: alle 3 Monate unter den Browser-Site-Daten-Einstellungen einmal durchgehen, alles raus, was du nicht erkennst.

FAQ

Sind Cookies an sich schlecht?

Nein — Cookies sind essentiell für moderne Web-Anwendungen. Login-Sessions, Warenkörbe, Sprache-Einstellungen funktionieren ohne sie nicht. Was problematisch ist, ist Cross-Site-Tracking über Third-Party-Cookies — und genau das ist heute in den Browsern stark eingeschränkt. First-Party-Cookies einer Seite, die du selbst besuchst, sind in der Regel unproblematisch.

Bringt es etwas, Cookies regelmäßig zu löschen?

Bedingt. Für Login-Sessions bedeutet es Neu-Anmeldungen. Für klassisches Tracking ist Storage Partitioning + Third-Party-Cookie-Blockierung wirksamer als manuelles Löschen. Wer „beim Beenden löschen" für nicht-essenzielle Sites aktiviert, hat ein gutes Mittelmaß.

Was ist mit IndexedDB?

IndexedDB ist mächtiger Browser-Datenbankspeicher, der von vielen Web-Apps für Offline-Funktionalität genutzt wird. Auch hier greift Storage Partitioning seit 2024. Manuelles Löschen über die Browser-Datenwerkzeuge möglich, aber für die meisten Nutzer:innen nicht nötig.

Wieso machen einige Sites trotzdem Probleme nach Cookie-Löschung?

Manche Web-Apps speichern komplexe Status in Cookies oder LocalStorage. Nach dem Löschen erscheinen Logins, gespeicherte Drafts, oder personalisierte Einstellungen weg. Lösung: vor regelmäßigem Aufräumen eine kurze "Welche Seiten brauche ich Login-erhaltend?"-Liste anlegen und in der Browser-Whitelist eintragen.

Was ist mit Sub-Domains? z. B. login.bank.de + bank.de

Cookies können per Domain-Attribut auf Sub-Domains gelten. Wenn die Bank das Cookie auf .bank.de setzt, gilt es für login.bank.de und mobile.bank.de. Wird oft korrekt eingesetzt — bei Verdacht auf falsche Konfiguration aber Vorsicht (z. B. wenn ein Mit-Tenants-Service auf tenant.example.de Cookies des Mutter-Dienstes lesen könnte).

Storage Partitioning ist nicht in allen Browsern gleich

Safari hat das früheste "Total Partitioning"-Verhalten (alle Storage-Typen). Firefox hat seit 2022 sehr ähnliches Verhalten. Chrome hat es schrittweise eingeführt und 2024 vollständig ausgerollt. Edge folgt Chrome. Wer Tor Browser oder Mullvad nutzt, hat noch striktere Partitioning-Strategien.

Cookie-Banner umgehen mit Extensions

Consent-O-Matic (Aarhus University) klickt automatisch das Banner-Ablehnen je nach Anbieter. I don't care about cookies (heute Avast/Mozilla) entfernt viele Banner — versteht aber nicht alle Anbieter. Beide reduzieren die Banner-Müdigkeit erheblich, ohne Privacy-Niveau zu senken.

Weiterführende Ressourcen

Externe Quellen

• MDN – HTTP Cookies
• MDN – Storage Partitioning
• Mozilla – Total Cookie Protection (Blog, 2022)
• WebKit – Intelligent Tracking Prevention
• Chromium – Privacy Sandbox / Storage Partitioning
• DSK Orientierungshilfe Telemedien
• TTDSG – Volltext
• noyb – Cookie-Banner-Beschwerden
• Consent-O-Matic Extension

Verwandte Artikel

• Tracking-Grundlagen
• Fingerprinting
• Tracker-Blocker
• Container-Tabs und Profile
• Cookie-Flags und Attribute (Entwickler-Sicht)
• Browser sicher einrichten