Cookies, Local Storage, Cache und Browser-Fingerprints erklärt

Diese Begriffe treten in Datenschutzeinstellungen, Anleitungen zur Fehlerdiagnose und Produkten für Browserprofile häufig gemeinsam auf. Ihr Verhalten unterscheidet sich so stark, dass „den Browser löschen“ keine vollständige Anweisung ist.

Ein praktisches Denkmodell

Mechanismus	Wer ihn erzeugt oder kontrolliert	Üblicher Geltungsbereich	Verbreiteter Zweck	Automatisch mit einer Anfrage gesendet?
HTTP-Cookie	Ein Server setzt ihn; der Browser speichert und übermittelt ihn nach Geltungsregeln	Host oder Domain, Pfad, Lebensdauer und Verbindungsbedingungen	Sitzungskennungen, Einstellungen, Missbrauchsschutz	Ja, wenn die Anfrage in seinen Geltungsbereich fällt
localStorage	Website-JavaScript	Origin, vorbehaltlich Browserpartitionierung und Richtlinien	Dauerhafter Schlüssel-Wert-Zustand einer Anwendung	Nein
sessionStorage	Website-JavaScript	Origin innerhalb einer Top-Level-Browsersitzung	Temporärer Zustand eines Tabs oder Arbeitsablaufs	Nein
HTTP-Cache	Browser und HTTP-Caching-Regeln	Cache-Schlüssel, Antwortanweisungen und Browserrichtlinie	Wiederverwendung von Antworten zur Verringerung von Latenz und Datenverkehr	Kann eine Anfrage bedienen oder revalidieren
Cache Storage API	Website- oder Service-Worker-JavaScript	Origin oder Speicherpartition	Offline-Ressourcen und von der Anwendung verwaltete Antworten	Keine automatische Beifügung; Skript steuert die Nutzung
Browser-Fingerprint	Eine Website oder andere beobachtende Stelle misst Signale	Hängt von Beobachter und Signalen ab	Sicherheit, Betrugserkennung, Analyse oder Tracking	Manche Signale sind in Anfragen sichtbar, andere erfordern aktiven Code

Die ersten fünf Zeilen betreffen gespeicherten Zustand. Die letzte Zeile beschreibt eine Methode zur Beobachtung und Korrelation, wobei gespeicherter Zustand ebenfalls zu ihren Eingaben gehören kann.

Cookies: serverseitiger Zustand mit Geltungsregeln

HTTP ist weitgehend zustandslos. Mit Cookies kann ein Server dem Browser ein Name-Wert-Paar geben und es bei späteren passenden Anfragen zurückerhalten. RFC 6265 definiert den Antwort-Header Set-Cookie, den Anfrage-Header Cookie und das Speichermodell des Browsers.

Ein Cookie kann sein:

• sitzungsbezogen, bis die vom Browser definierte Sitzung endet;
• dauerhaft, mit Ablaufdatum oder Höchstalter;
• hostgebunden, sodass er nur an den Host zurückgesendet wird, der ihn gesetzt hat;
• domainbezogen, sodass er für die angegebene Domain und passende Subdomains infrage kommt;
• pfadbezogen, sodass er nur für passende Anfragepfade zurückgesendet wird;
• Secure, sodass er nur über einen vom Browser als sicher definierten Kanal gesendet wird; und
• HttpOnly, sodass er vor skriptseitigen Cookie-APIs verborgen bleibt, aber für HTTP-Anfragen verfügbar ist.

Diese Attribute beeinflussen Übermittlung und Skriptzugriff. Sie machen den Cookie-Wert nicht zu einer eigenständigen Sicherheitsgrenze. RFC 6265 warnt ausdrücklich davor, sich beim Schutz auf das Attribut Path zu verlassen, und empfiehlt für vertrauliche Cookie-Inhalte eine sichere Übertragung sowie zusätzlichen Schutz.

Weshalb das Löschen von Cookies abmeldet

Viele Dienste speichern eine zufällige Sitzungskennung in einem Cookie, während Kontodatensatz und Sitzungsdetails auf dem Server verbleiben. Durch das Löschen dieses Cookies verliert der Browser seine Kopie der Kennung; die nächste Anfrage weist daher nicht mehr dieselbe Sitzung aus. Das serverseitige Konto und andere Sitzungen können fortbestehen.

Dies erklärt auch, warum das Kopieren von Authentifizierungs-Cookies vertraulich ist. Eine nutzbare Sitzungskennung kann wie ein Zugangsnachweis wirken. Fügen Sie ungeschützte Cookies nicht in Tickets, Protokolle, Automatisierungsausgaben oder Teamchats ein.

Local Storage: skriptgesteuerter Zustand für eine Origin

Der HTML Standard definiert localStorage als Zugriff auf den lokalen Speicherbereich einer Origin. Er soll fensterübergreifend bestehen und die aktuelle Sitzung überdauern. Der Speicher enthält Schlüssel-Wert-Paare aus Zeichenketten und steht Skripten zur Verfügung, die mit der Berechtigung dieser Origin ausgeführt werden.

Eine Origin besteht normalerweise aus Schema, Host und Port. Deshalb gehören diese Adressen zu unterschiedlichen Speicherbereichen:

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

Der URL-Pfad gehört nicht zur Origin. Seiten unter /billing/ und /support/ auf derselben Origin können daher denselben lokalen Speicherbereich verwenden, sofern die Anwendung keine eigene logische Trennung anlegt.

Anders als ein Cookie wird ein localStorage-Eintrag nicht automatisch an HTTP-Anfragen angehängt. Das Website-Skript muss ihn lesen und über seine Verwendung entscheiden. Dadurch eignet er sich für Oberflächeneinstellungen, Entwürfe und Anwendungsdaten. Jedes Skript, das mit der Berechtigung der Origin ausgeführt wird, kann jedoch möglicherweise darauf zugreifen. Designs für vertrauliche Sitzungen sollten die Kompromittierung von Skripten berücksichtigen, statt „lokal“ mit „geheim“ gleichzusetzen.

Beständigkeit bedeutet hier, dass Daten eine Browsersitzung überdauern können. Sie bedeutet keine dauerhafte Aufbewahrung. Nutzende können die Daten löschen, Browserrichtlinien können sie einschränken und der Browser kann Speicher- und Verdrängungsregeln anwenden.

sessionStorage hat eine andere Lebensdauer

sessionStorage ist einer Origin und einer Top-Level-Browsersitzung zugeordnet. Er eignet sich für Zustand, der während eines Tab- oder Fensterablaufs erhalten und mit dieser Sitzung beendet werden soll. Bei geklonten oder wiederhergestellten Tabs können browserspezifische Einzelheiten des Lebenszyklus eine Rolle spielen. Anwendungen sollten ihn daher nicht als einzigen Datensatz kritischer Arbeit verwenden.

Local Storage ist nur ein Mechanismus für Websitedaten

Moderne Webanwendungen können Daten außerdem in IndexedDB, Cache Storage, Service-Worker-Registrierungen, dem Origin Private File System, Berechtigungen und weiteren vom Browser verwalteten Speichern ablegen. Wird in den Entwicklerwerkzeugen nur localStorage gelöscht, kann anderer Zustand erhalten bleiben.

Die Datenschutzhinweise des HTML Standards empfehlen Browsern, Nutzenden das gemeinsame Löschen dauerhafter Speichermechanismen zu ermöglichen. Andernfalls könnte eine Website einen Speicher verwenden, um eine aus einem anderen Speicher entfernte Kennung wiederherzustellen.

Cache: ein Wort für mehrere Mechanismen

Der HTTP-Cache

RFC 9111 definiert einen HTTP-Cache als Speicher für Antwortnachrichten und als System, das deren Ablage, Abruf und Löschung steuert. Ein Browser-Cache kann eine aktuelle Antwort wiederverwenden oder eine veraltete revalidieren und dadurch Latenz und Netzwerkübertragung verringern.

Der Cache-Schlüssel umfasst mindestens die Anfragemethode und Ziel-URI; Antwort-Header beeinflussen, ob und wie lange eine Antwort wiederverwendet werden kann. Der HTTP-Cache dient der Optimierung. Ein zwischengespeichertes Bild oder Skript bedeutet normalerweise nicht, dass die Person angemeldet ist.

Cache-Zustand kann den Datenschutz dennoch beeinflussen. In manchen Bedrohungsmodellen kann die Dauer oder die bereits vorhandene Verfügbarkeit einer Ressource Informationen offenlegen. Die Fingerprinting-Leitlinie des W3C zählt Beobachtungen zwischengespeicherter Ressourcen zu den Möglichkeiten, Browser- oder Benutzerkonfigurationen abzuleiten.

Cache Storage und Service Worker

Die Cache Storage API stellt einer Website ausdrückliche, skriptgesteuerte Cache-Objekte bereit, häufig für Offline-Webanwendungen. Die Service-Workers-Spezifikation hält fest, dass diese Caches vom HTTP-Cache des Browsers getrennt und nach Origin isoliert sind sowie durch Anwendungslogik statt durch gewöhnliche HTTP-Aktualitätsregeln aktualisiert oder gelöscht werden.

Dieser Unterschied ist bei der Fehlerdiagnose wichtig:

• Das Löschen von „Bilder und Dateien im Cache“ zielt auf den gewöhnlichen Browser-Cache.
• Das Löschen von Websitedaten kann zusätzlich Cache Storage und Service-Worker-Zustand entfernen.
• Beim erneuten Laden unter Umgehung des HTTP-Caches kann ein aktiver Service Worker weiterhin Anfragen steuern.

Benennen Sie den gemeinten Cache, bevor Sie über Prüfung oder Löschung entscheiden.

Speicherpartitionierung ergänzt einen weiteren Schlüssel

Der Geltungsbereich einer Origin erlaubte einem eingebetteten Drittanbieter früher, denselben Speicher zu lesen, wenn er in verschiedenen Top-Level-Websites erschien. Moderne Browser beziehen zunehmend die Top-Level-Website oder einen verwandten Kontext in den Speicherschlüssel ein.

Chrome dokumentiert, dass seine Speicherpartitionierung verhindert, dass ein auf a.com eingebetteter Frame von example.com automatisch Local Storage, IndexedDB, Cache Storage, Service Worker und bestimmte Kommunikationsmechanismen mit demselben auf b.com eingebetteten Frame teilt. Laut Chrome ist dies seit Chrome 115 für alle Nutzenden aktiviert; bei einigen zusätzlichen APIs folgten später Änderungen.

Die Partitionierung erklärt ein ansonsten überraschendes Ergebnis: Dieselbe eingebettete Origin kann abhängig von der umgebenden Website unterschiedliche Speicher sehen. Das bedeutet nicht, dass jeder Speicher überall einem universellen Zwei-Schlüssel-Modell folgt. Browserversionen, Top-Level- und eingebettete Kontexte, erteilte Speicherzugriffe, Unternehmensrichtlinien, Erweiterungen und API-spezifische Regeln können das Ergebnis verändern.

Testen Sie den konkreten Kontext, statt allein aus dem Domainnamen darauf zu schließen.

Browser-Fingerprints: beobachtete Signale, kein Ordner

Das W3C definiert Browser-Fingerprinting als die Fähigkeit, Nutzende, User Agents oder Geräte anhand von Konfigurationseinstellungen oder anderen beobachtbaren Merkmalen zu identifizieren oder wiederzuerkennen. Seine Leitlinie von 2025 unterscheidet mehrere Formen:

• Passives Fingerprinting nutzt bereits in Anfragen oder im Netzwerk sichtbare Informationen wie Anfrage-Header und IP-Adresse.
• Aktives Fingerprinting führt Code aus, um Merkmale wie Fenstergröße, Schriftarten, angeschlossene Geräte, Leistung, Sensoren oder Grafikdarstellung zu beobachten.
• Korrelation vorübergehender Ereignisse verbindet Kontexte durch nahezu gleichzeitige Änderungen am Gerät oder an der Umgebung.
• Cookieähnliche Verfahren speichern und lesen Zustand über Mechanismen, die gewöhnliche Cookies überdauern oder neu erzeugen können.

Ein Fingerprint ist selten ein einzelner unveränderlicher Wert, den der Browser speichert. Eine beobachtende Stelle wählt Signale, kombiniert sie und entscheidet, wie stark sie mit einem früheren Besuch übereinstimmen. Das Ergebnis kann sich ändern, wenn der Browser aktualisiert, das Fenster verändert, eine Schriftart hinzugefügt, ein Gerät verbunden oder der Netzwerkweg gewechselt wird. Es kann nach dem Löschen von Cookies ähnlich bleiben, weil viele zugrunde liegende Signale unverändert sind.

Fingerprinting ist kein Identitätsnachweis

Ein Signalsatz kann bei vielen Menschen gleich sein oder bei einer Person im Laufe der Zeit abweichen. Websites können einen Fingerprint außerdem mit einer Anmeldung, serverseitigem Kontoverlauf, Netzwerkreputation oder gespeicherten Kennungen kombinieren. Eine Wiedererkennung nach Datenlöschung beweist daher nicht, dass Fingerprinting allein die Ursache war.

Aus demselben Grund garantiert die Änderung einer sichtbaren Einstellung keine neue Identität. Eine stimmige, verbreitete Konfiguration kann manche Einzigartigkeit verringern; viele ungewöhnliche Einzeländerungen können dagegen eine seltenere Kombination schaffen. Diese Signale erlauben weder eine Garantie für Unsichtbarkeit noch für die Akzeptanz durch Dritte.

Was verbreitete Löschaktionen tatsächlich verändern

Aktion	Wahrscheinliche Wirkung	Wichtige verbleibende Daten
Cookies einer Website löschen	Entfernt passende, vom Browser gehaltene Cookie-Zustände und meldet dieses Profil häufig ab	Serverseitige Kontodaten, andere Geräte und Nicht-Cookie-Speicher können erhalten bleiben
Cookies und andere Websitedaten löschen	Kann je nach Browseroberfläche und Geltungsbereich Cookies, Web Storage, IndexedDB, Service Worker und verwandten Websitezustand entfernen	Passwortmanager, Downloads, kontoseitige Daten und beobachtbare Gerätesignale sind getrennt
Bilder und Dateien im Cache löschen	Entfernt gewöhnliche zwischengespeicherte Antwortinhalte	Cookies, Local Storage und Cache Storage müssen möglicherweise getrennt ausgewählt werden
Verlauf löschen	Entfernt aufgezeichnete besuchte URLs und zugehörige Vorschläge im gewählten Geltungsbereich	Heruntergeladene Dateien und von der Website gehaltene Datensätze bleiben erhalten
Ein Browserprofil entfernen	Entfernt dessen lokale Lesezeichen, Verlauf, Passwörter und andere Einstellungen vom Gerät	Synchronisierte Kontodaten, heruntergeladene oder exportierte Dateien, Sicherungen und serverseitige Daten können erhalten bleiben
Neues Profil starten	Beginnt mit einer anderen Sammlung von Profilzuständen	Gerät, Betriebssystem, Browser-Build und Netzwerk können weiterhin als zusammengehörig erkannt werden

Chromes eigener Ratgeber zu Browserdaten behandelt Verlauf, Cookies und andere Websitedaten, Bilder und Dateien im Cache, Downloadverlauf, AutoFill, Websiteeinstellungen und Daten gehosteter Apps als getrennte Kategorien. Er weist außerdem darauf hin, dass beim Löschen des Downloadverlaufs die heruntergeladenen Dateien auf dem Computer verbleiben und dass das Löschen angemeldeter Daten das Google-Konto und andere synchronisierte Geräte betreffen kann.

Die genaue Wirkung hängt von ausgewähltem Zeitraum, Profil, Kontostatus, Browserversion und Unternehmensrichtlinie ab. Lesen Sie den Bestätigungstext, bevor Sie möglicherweise schwer wiederherstellbare Daten löschen.

Wie separate Browserprofile die einzelnen Mechanismen beeinflussen

Ein korrekt getrenntes dauerhaftes Profil sollte einen eigenen Cookie-Speicher, eigene Web-Storage-Bereiche, Website-Datenbanken, Cache Storage, Zuständigkeit für den HTTP-Cache, Verlauf, Websiteberechtigungen und Erweiterungszustand besitzen. Dadurch übernimmt Profil B nicht einfach die gespeicherte Sitzung von Profil A.

Mehrere Signale können gemeinsam bleiben:

• Browser-Engine und Version;
• Betriebssystem und Hardware;
• installierte Systemschriftarten und Anzeigeeigenschaften;
• vom Host übernommene Sprach-, Zeitzonen- oder Barrierefreiheitseinstellungen;
• IP-Adresse und Netzwerkweg, wenn kein separater Weg konfiguriert ist; und
• Bedienverhalten oder Anmeldungen, die Aktivitäten auf Anwendungsebene verknüpfen.

Unterschiedliche Profile können durch Erweiterungen, Berechtigungen, Fenstergrößen, Spracheinstellungen oder Proxy-Wege auch unterschiedliche Signale offenlegen. Die Gesamtwirkung hängt von Umsetzung und Kontext ab. Profiltrennung sollte als Zustandsisolierung bewertet werden, nicht als Fingerprint-Garantie.

Diagnostizieren Sie das Symptom, bevor Sie alles löschen

„Ich wurde abgemeldet“

Prüfen Sie zuerst Cookies. Ein Sitzungscookie kann abgelaufen, gelöscht, durch eine Browserrichtlinie abgelehnt oder vom Server ungültig gemacht worden sein. Local Storage kann die Oberfläche unterstützen, ist aber normalerweise nicht der Cookie, der automatisch zur Authentifizierung einer HTTP-Anfrage gesendet wird.

„Die Website hat meinen Entwurf oder meine Offlinedaten vergessen“

Prüfen Sie Local Storage, IndexedDB, Cache Storage und Service-Worker-Zustand. Bestätigen Sie die Origin und ob die Seite auf oberster Ebene oder in eine andere Website eingebettet ist, da die Partitionierung den verfügbaren Speicher verändern kann.

„Das erste Neuladen ist langsam“

Ein leerer oder veralteter HTTP-Cache ist eine wahrscheinliche Ursache. Netzwerk, Server und Service Worker können dasselbe Symptom erzeugen; zeichnen Sie deshalb Anfragezeiten und Cache-Status auf, bevor Sie eine Schlussfolgerung ziehen.

„Die Website erkennt die Umgebung nach dem Löschen der Daten weiterhin“

Mehrere Erklärungen bleiben möglich: Das Konto ist an anderer Stelle noch angemeldet, der Server hat den Besuch über Konto- oder Netzwerkdaten verknüpft, ein anderer Browserspeicher ist erhalten geblieben oder beobachtbare Merkmale haben die Sitzungen korreliert. Behandeln Sie Fingerprinting als eine Hypothese, nicht als automatische Antwort.

Entscheidungsorientiertes Fazit

Wählen Sie die Maßnahme passend zum Mechanismus:

• Prüfen oder löschen Sie Cookies, wenn es um Serversitzungen geht.
• Prüfen Sie originbezogene Websitespeicher, wenn eine Webanwendung lokalen Zustand beibehält.
• Unterscheiden Sie bei veralteten oder Offline-Inhalten den HTTP-Cache vom Cache Storage.
• Verwenden Sie ein separates dauerhaftes Profil, wenn gespeicherter Arbeitszustand unabhängig bleiben muss.
• Behandeln Sie Fingerprinting als Korrelation beobachtbarer Signale, deren Grenzen durch Datenlöschung oder die Änderung einer einzelnen Einstellung nicht verschwinden.

Dieses Modell vermeidet zwei kostspielige Fehler: mehr Zustand als nötig zu löschen und anzunehmen, dass ein leerer Cookie-Speicher eine neue Geräteidentität schafft.

Einschränkungen

Webspeicher- und Datenschutzverhalten entwickelt sich browser- und releaseübergreifend weiter. Regeln für Drittanbieter-Cookies, Speicherpartitionierung, Verdrängung, Synchronisierung, Unternehmensrichtlinien, Erweiterungen und private Browsermodi können das hier beschriebene Verhalten verändern. Dieser Ratgeber erläutert die Standards und die zum Abrufdatum aktuelle Chrome-Dokumentation; er beschreibt nicht jede Browser- oder Websiteimplementierung.