Local Storage, Session Storage und Fingerprinting

Cookies sind nicht der einzige Ort, an dem eine Website Daten in deinem Browser ablegen kann. Moderne Browser bieten eigene Speicher an, vor allem Local Storage und Session Storage, zusammengefasst als Web Storage, und für größere Datenmengen die Datenbank IndexedDB. Daneben gibt es Verfahren, die einen Browser ganz ohne gespeicherte Kennung wiedererkennen. Das bekannteste heißt Fingerprinting. Die Grundlagen zum Cookie selbst stehen unter Was Cookies sind und wie sie funktionieren.

Speicher im Browser neben dem Cookie

In den frühen Jahren des Webs dienten Cookies auch als allgemeiner Datenspeicher im Browser, weil es nichts anderes gab. Heute empfiehlt die Entwicklerdokumentation von Mozilla dafür die Web Storage API mit localStorage und sessionStorage sowie IndexedDB ^[13]. Diese Speicher senden ihre Daten nie von selbst an den Server und fassen mehr als ein Cookie ^[13]. Der Webstandard HTML beschreibt Web Storage als zwei verwandte Mechanismen, die ähnlich wie Session-Cookies Paare aus Name und Wert im Browser ablegen ^[1].

Beide Speicher sind an den Ursprung gebunden, also an die Kombination aus Protokoll, Domain und Port ^[14]. Jeder Ursprung hat sein eigenes Speicherobjekt für localStorage und eines für sessionStorage ^[2]. Innerhalb eines Ursprungs gibt es keine Trennung nach Pfaden. Teilen sich mehrere Betreiber einen Host, teilen sie sich auch den Speicher ^[1].

Local Storage

Local Storage ist für Daten gedacht, die über mehrere Fenster hinweg gelten und länger halten als die aktuelle Sitzung ^[1]. Alle Seiten desselben Ursprungs greifen auf denselben Bereich zu, und er bleibt bestehen, wenn du den Browser schließt und wieder öffnest ^[2]. Ein Ablaufdatum wie beim Cookie gibt es nicht. Die Daten bleiben, bis die Website sie löscht, du sie entfernst oder der Browser sie räumt, etwa wenn der Speicherplatz knapp wird ^[3].

Der Platz ist begrenzt. Nach Mozilla speichern Browser je Ursprung bis zu 5 MiB im Local Storage und weitere 5 MiB im Session Storage. Ist die Grenze erreicht, bricht das Schreiben mit dem Fehler QuotaExceededError ab ^[3]. IndexedDB teilt sich ein deutlich größeres Kontingent mit anderen Speichern. In Chrome und Edge darf ein Ursprung bis zu 60 Prozent des gesamten Festplattenplatzes belegen ^[3].

Der Standard rechnet damit, dass Web-Anwendungen Megabytes an Nutzerdaten im Browser ablegen wollen, etwa ganze Dokumente oder ein Postfach ^[1].

Session Storage

Session Storage gilt für ein einzelnes Fenster oder einen Tab. Was eine Website dort ablegt, sehen alle Seiten desselben Ursprungs, die in diesem Fenster geöffnet werden ^[1]. Schließt du den Tab, löscht der Browser alle zugehörigen Daten ^[2]. Ein zweiter Tab mit derselben Website bekommt einen eigenen Bereich.

Der Standard begründet das mit einem Beispiel: Wer auf derselben Website in zwei Fenstern gleichzeitig Flugtickets kauft, könnte mit Cookies durcheinandergeraten, weil Cookies in allen Fenstern gelten. Session Storage hält die beiden Vorgänge getrennt ^[1].

Unterschiede zum Cookie

Die drei Speicher im Vergleich ^{[1, 2, 3, 13]}:

Wie HttpOnly und die anderen Cookie-Attribute arbeiten, erklärt Cookie-Attribute: Secure, HttpOnly und SameSite.

Was nicht in den Speicher gehört

Web Storage ist für JavaScript immer lesbar. Gelingt einem Angreifer ein Cross-Site-Scripting, also das Einschleusen eines eigenen Skripts in die Seite, kann er damit alle Daten aus diesen Speichern abgreifen ^[4]. Das OWASP-Projekt für Webanwendungssicherheit rät deshalb, keine Sitzungskennungen im Local Storage abzulegen. Cookies lassen sich mit HttpOnly vor diesem Zugriff schützen ^[4].

Wer Daten nicht dauerhaft braucht, soll nach OWASP sessionStorage statt localStorage nehmen ^[4]. Und weil ein eingeschleustes Skript auch in den Speicher schreiben kann, sollte eine Anwendung den gespeicherten Werten nicht blind vertrauen ^[4].

Tracking mit Web Storage

Local Storage eignet sich wie ein Cookie dazu, eine Kennung dauerhaft abzulegen. Der HTML-Standard nennt das Risiko selbst: Ein Werbeanbieter, dessen Inhalte auf vielen Websites eingebunden sind, könnte eine eindeutige Kennung in seinem Speicherbereich ablegen und dich damit über mehrere Sitzungen verfolgen. Browser können das begrenzen, etwa indem sie Speicher von Drittanbietern sperren oder Daten verfallen lassen ^[1].

Firefox trennt den Speicher eingebetteter Inhalte nach der besuchten Website: Ein fremder Inhalt auf Website A bekommt einen anderen Bereich als derselbe Inhalt auf Website B. Das betrifft unter anderem localStorage, sessionStorage und IndexedDB, und seit Firefox 103 ist diese Trennung für alle eingeschaltet ^[5]. Chrome partitioniert den Speicher in eingebetteten Inhalten seit Version 115 für alle Nutzer, ebenfalls mit Local Storage, Session Storage und IndexedDB ^[6].

Seit Safari 13.1 vom März 2020 löscht der Browser bei eingeschaltetem Schutz vor seitenübergreifendem Tracking allen per Skript beschreibbaren Speicher einer Website, darunter IndexedDB, Local Storage und Session Storage, wenn du sie an sieben Tagen der Safari-Nutzung nicht angeklickt oder angetippt hast ^{[7, 3]}. Vom Server gesetzte Cookies sind davon ausgenommen, ebenso Web-Apps, die du auf den Home-Bildschirm gelegt hast ^{[3, 7]}. Wie Cookies von Drittanbietern behandelt werden, steht unter Drittanbieter-Cookies und Tracking.

Fingerprinting

Fingerprinting braucht keinen Speicher. Die Datenschutzkonferenz beschreibt Browser-Fingerprinting als das Bilden eines möglichst eindeutigen und langlebigen Werts aus Browser-Informationen wie Bildschirmauflösung, Version des Betriebssystems oder installierten Schriften ^[10]. Die Arbeitsgruppe für Privatsphäre des W3C, des Gremiums für Webstandards, definiert es als die Fähigkeit einer Website, einen Nutzer, Browser oder ein Gerät anhand von Einstellungen und anderen beobachtbaren Merkmalen zu erkennen oder wiederzuerkennen ^[8].

Passiv und aktiv

Das W3C beschreibt unter anderem zwei Formen. Beim passiven Fingerprinting wertet der Server nur aus, was ohnehin bei jeder Anfrage ankommt, etwa die Kopfzeilen und die IP-Adresse. Die Kennung des Browsers, der User-Agent, nennt typischerweise Browser, Version und Betriebssystem ^[8]. Beim aktiven Fingerprinting führt die Website Code im Browser aus und fragt weitere Merkmale ab, zum Beispiel Fenstergröße, vorhandene Schriften, angeschlossene Geräte, Sensorwerte oder das Ergebnis beim Zeichnen von Grafiken ^[8].

Wie eindeutig ein Browser ist

Wie gut das funktioniert, zeigte 2010 eine Untersuchung der Electronic Frontier Foundation. Peter Eckersley wertete die Merkmale von 470.161 Browsern aus, deren Nutzer freiwillig eine Testseite besucht hatten. 83,6 Prozent dieser Browser hatten einen Fingerabdruck, den es im Datensatz nur einmal gab. Bei Browsern mit Flash oder Java waren es 94,2 Prozent ^[9]. Fingerabdrücke änderten sich zwar oft, ein einfaches Verfahren erkannte veränderte Abdrücke wieder, und 99,1 Prozent seiner Zuordnungen stimmten ^[9]. Eckersley nennt seine Stichprobe selbst stark verzerrt: Sie bildet vor allem Nutzer ab, die auf ihre Privatsphäre achten ^[9].

Supercookies und andere Umwege

Zwischen Speicher und Fingerabdruck liegen Verfahren, die Browser-Funktionen zweckentfremden. Das W3C warnt vor sogenannten Supercookies, Zombie-Cookies oder Evercookies: Eine Website legt Zustandsinformationen an mehreren Stellen ab und stellt gelöschte Kennungen daraus wieder her. So lassen sich Versuche umgehen, Cookies zu begrenzen oder zu löschen ^[8]. Als Beispiel nennt das W3C den HSTS-Supercookie, bei dem schon ein einzelnes gespeichertes Bit missbraucht wird ^[8]. Mit HSTS legt ein Server eigentlich fest, welche Inhalte der Browser stets über HTTPS anfordern soll ^[11].

Der Europäische Datenschutzausschuss zählt weitere Mechanismen auf, die zur Erfassung von Informationen genutzt werden können: Kopfzeilen wie Accept und User-Agent, Zwischenspeicher-Kennungen wie das ETag und eben HSTS ^[11].

Matomo erkennt Besucher ohne Cookies an einer Kennung, die es aus Umgebungsinformationen bildet. Matomo nennt diese Informationen selbst "a fingerprint" und speichert davon nur einen Hashwert, der höchstens 24 Stunden in der Datenbank bleibt ^[12]. Wie diese Websites ihre Reichweite ohne Cookies messen, beschreiben Website ohne Cookie-Banner betreiben und Inhalte mit Matomo auswerten.

Was das Recht dazu sagt

§ 25 TDDDG ist technikneutral formuliert und erfasst neben Cookies auch Local Storage und Session Storage ^[10]. Liest ein Skript Eigenschaften deines Geräts aus und schickt sie an einen Server, um einen Fingerabdruck zu bilden, gilt das ebenfalls als Zugriff ^[10]. Der Europäische Datenschutzausschuss sieht es ähnlich: Solange ein Browser gespeicherte Informationen nur auf dem Gerät verwendet, liegt kein Zugriff vor. Verlassen die Informationen oder daraus abgeleitete Werte das Gerät, greift die Regel ^[11]. Dass dein Browser Cookies oder Web Storage grundsätzlich zulässt, ist nach der Datenschutzkonferenz keine Einwilligung ^[10]. Wann eine Website deshalb fragen muss, steht unter Wann eine Website für Cookies eine Einwilligung braucht.

Den Speicher selbst ansehen

Chrome zeigt Local Storage und Session Storage in den Entwicklerwerkzeugen im Bereich Application. Dort lassen sich einzelne Einträge ansehen, bearbeiten und löschen ^[15]. Der Storage Inspector von Firefox listet für die geöffnete Website Local Storage und Session Storage mit ihren Einträgen auf ^[16]. Wer gar nichts behalten will, nutzt ein privates Fenster: Dort behandeln Browser Local Storage wie Session Storage und löschen alles, sobald das Fenster oder der Tab geschlossen wird ^[2]. Wie du Websitedaten dauerhaft entfernst, zeigt Cookies im Browser löschen und blockieren.

Welche Einträge eine bestimmte Website gleich beim ersten Aufruf in den Local Storage schreibt, listet der Cookie-Checker mit Schlüssel und Wert auf.

1. Gesetz HTML Living Standard, Abschnitt 12: Web storage. WHATWG. Stand ohne Datum (laufend gepflegt). abgerufen am 29.10.2026
2. Organisation Web Storage API. Mozilla, MDN Web Docs. Stand ohne Datum. abgerufen am 29.10.2026
3. Organisation Storage quotas and eviction criteria. Mozilla, MDN Web Docs. Stand ohne Datum. abgerufen am 29.10.2026
4. Organisation HTML5 Security Cheat Sheet. OWASP Foundation, OWASP Cheat Sheet Series. Stand ohne Datum. abgerufen am 29.10.2026
5. Organisation State Partitioning. Mozilla, MDN Web Docs. Stand ohne Datum. abgerufen am 29.10.2026
6. Organisation Storage Partitioning. Google, Privacy Sandbox. Stand 13.06.2025. abgerufen am 29.10.2026
7. Organisation Full Third-Party Cookie Blocking and More. WebKit (Apple), John Wilander. Stand 24.03.2020. abgerufen am 29.10.2026
8. Organisation Mitigating Browser Fingerprinting in Web Specifications, W3C Group Note. W3C Privacy Working Group. Stand 25.09.2025. abgerufen am 29.10.2026
9. Studie How Unique Is Your Web Browser?. Peter Eckersley, Electronic Frontier Foundation. Stand 2010. abgerufen am 29.10.2026
10. Behörde Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von digitalen Diensten (OH Digitale Dienste), Version 1.2. Datenschutzkonferenz (DSK). Stand November 2024. abgerufen am 29.10.2026
11. Behörde Leitlinien 2/2023 zum technischen Anwendungsbereich von Artikel 5 Absatz 3 der Datenschutzrichtlinie für elektronische Kommunikation, Version 2.0. Europäischer Datenschutzausschuss (EDSA). Stand 07.10.2024. abgerufen am 29.10.2026
12. Organisation How does Matomo detect unique and returning visitors?. Matomo. Stand ohne Datum. abgerufen am 29.10.2026
13. Organisation Verwendung von HTTP-Cookies. Mozilla, MDN Web Docs. Stand ohne Datum. abgerufen am 29.10.2026
14. Organisation Ursprung (Origin). Mozilla, MDN Web Docs. Stand ohne Datum. abgerufen am 29.10.2026
15. Organisation View and edit local storage. Google, Chrome for Developers, Chrome DevTools. Stand zuletzt aktualisiert 14.03.2019. abgerufen am 29.10.2026
16. Organisation Storage Inspector. Mozilla, Firefox Source Docs. Stand ohne Datum. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.