Kurze Antwort: SessionStorage und localStorage sind beides browserbasierte Web Storage APIs, die es Websites ermöglichen, Daten auf dem Gerät eines Benutzers zu speichern. Sie unterscheiden sich jedoch kritisch in Bezug auf Persistenz und Geltungsbereich. localStorage behält Daten unbegrenzt über Sitzungen und Tabs hinweg bei, während sessionStorage Daten löscht, wenn der Browser-Tab geschlossen wird. Aus Datenschutzsicht birgt localStorage ein wesentlich höheres Risiko, da Daten ohne Ablaufdatum verbleiben, was es zu einem attraktiveren Ziel für Tracking, Fingerprinting und regulatorische Prüfungen unter Rahmenwerken wie der DSGVO macht.
Wichtigste Erkenntnisse
- localStorage bleibt unbegrenzt bestehen, bis es explizit gelöscht wird; sessionStorage wird gelöscht, wenn der Tab oder das Fenster geschlossen wird.
- Beide Speichertypen sind anfällig für Cross-Site-Scripting (XSS)-Angriffe und bieten keine integrierte Verschlüsselung.
- Weder localStorage- noch sessionStorage-Daten werden automatisch an den Server übertragen, im Gegensatz zu Cookies, aber beide sind vollständig von jedem JavaScript lesbar, das auf demselben Ursprung ausgeführt wird.
- Drittanbieter-Skripte, die auf einer Seite geladen werden, können auf localStorage-Daten zugreifen, wenn sie im selben Ursprungskontext ausgeführt werden.
- Gemäß der DSGVO ist das Speichern nicht-essentieller Daten in localStorage ohne Benutzerzustimmung ein Verstoß gegen die Compliance, ebenso wie das Setzen von Tracking-Cookies.
- Sensible Daten wie Authentifizierungstoken, Passwörter und persönlich identifizierbare Informationen (PII) sollten niemals ohne zusätzliche Sicherheitsebenen in einem der beiden Mechanismen gespeichert werden.
- Privates/Inkognito-Browsen begrenzt die Persistenz von localStorage, eliminiert aber nicht die sessionStorage-Risiken innerhalb einer Sitzung.
- Entwickler sollten sessionStorage für temporäre Zustände, serverseitige Sitzungen oder HttpOnly-Cookies für die Authentifizierung bevorzugen und eine Consent Management Platform wie Biscotti CMP zur Verwaltung der Speicherzustimmung verwenden.
Was ist der Unterschied zwischen SessionStorage und LocalStorage?
SessionStorage und localStorage sind beide Teil der HTML5 Web Storage API, dienen aber unterschiedlichen Zwecken, die durch ihre Persistenz und ihr Tab-Scope-Verhalten definiert sind.
localStorage speichert Schlüssel-Wert-Paare ohne Ablaufdatum. Daten überleben Browser-Neustarts, System-Neustarts und unbegrenzte Inaktivitätszeiten, bis der Benutzer oder die Anwendung sie explizit entfernt. Es wird über alle Tabs und Fenster hinweg geteilt, die unter demselben Ursprung (Protokoll + Domain + Port) arbeiten. [1][5]
sessionStorage speichert Daten nur für die Lebensdauer der Seiten-Sitzung. Wenn der Benutzer den Tab oder das Fenster schließt, sind die Daten verschwunden. Entscheidend ist, dass jeder Tab sein eigenes isoliertes sessionStorage verwaltet; das Öffnen derselben URL in einem zweiten Tab teilt die sessionStorage-Daten des ersten Tabs nicht. [1]
| Merkmal | localStorage | sessionStorage |
|---|---|---|
| Persistenz | Unbegrenzt | Nur für die Lebensdauer des Tabs/Fensters |
| Über Tabs hinweg geteilt | Ja (gleicher Ursprung) | Nein (pro-Tab-Isolation) |
| Überlebt Seitenneuladen | Ja | Ja |
| Überlebt Tab-Schließen | Ja | Nein |
| Speicherkapazität | ~5-10 MB pro Ursprung | ~5-10 MB pro Ursprung |
| Serverübertragung | Nein | Nein |
| HttpOnly-Schutz | Nicht verfügbar | Nicht verfügbar |
Beide APIs halten sich an die Same-Origin-Policy, sodass eine Seite unter https://example.com keinen Speicher lesen kann, der von https://otherdomain.com gesetzt wurde. [4]
Birgt localStorage im Vergleich zu sessionStorage Datenschutzrisiken?
Ja, localStorage birgt wesentlich höhere Datenschutzrisiken als sessionStorage, hauptsächlich aufgrund seiner unbegrenzten Persistenz und der Zugänglichkeit über mehrere Tabs hinweg.
Daten, die in localStorage geschrieben werden, können sich über Monate oder Jahre ansammeln, ohne dass der Benutzer davon Kenntnis hat. Werbetreibende und Analyseanbieter haben localStorage historisch als "Super-Cookie" verwendet, einen Tracking-Identifikator, der die Löschung von Cookies überlebt, da die meisten Benutzer nicht daran denken, den Browser-Speicher manuell zu löschen. sessionStorage hingegen löscht sich beim Schließen des Tabs selbst, was es zu einem weitaus weniger nützlichen Tracking-Vektor macht.
Wichtige Datenschutzrisikofaktoren, die für localStorage einzigartig sind:
- Persistente Tracking-Identifikatoren: Eine eindeutige ID, die in localStorage gespeichert ist, kann einen Benutzer über mehrere Besuche hinweg verfolgen, ohne dass ein serverseitiges Cookie erforderlich ist.
- Datenlecks über Tabs hinweg: Jedes Skript, das in einem beliebigen Tab desselben Ursprungs ausgeführt wird, kann alle localStorage-Daten lesen.
- Storage-Ereignis-Broadcasting: Änderungen an localStorage lösen ein
storage-Ereignis in anderen offenen Tabs desselben Ursprungs aus, was eine tabübergreifende Datensynchronisation ermöglicht, die Benutzer nicht beobachten können. [5] - Kein automatisches Ablaufdatum: Im Gegensatz zu Cookies, die
Max-Age- undExpires-Attribute unterstützen, hat localStorage keinen TTL-Mechanismus.
Können Websites Benutzer mit localStorage und sessionStorage verfolgen?
Websites können und nutzen localStorage für persistentes Tracking. sessionStorage ist weniger nützlich für Tracking, birgt aber dennoch Risiken der Überwachung innerhalb einer Sitzung.
Eine einzige JavaScript-Zeile, localStorage.setItem('uid', 'abc123'), erstellt einen persistenten Identifikator, der die Cookie-Löschung überlebt. Diese Technik, manchmal als "Evercookie" oder speicherbasiertes Respawning bezeichnet, wurde in der Datenschutzforschung dokumentiert und ist der Grund, warum Regulierungsbehörden localStorage zunehmend unter denselben Zustimmungsregeln wie Cookies behandeln.
sessionStorage kann das Verhalten innerhalb einer einzelnen Sitzung verfolgen (Seitenfluss, Formulareingaben, Navigationsmuster), aber diese Daten verschwinden, wenn der Tab geschlossen wird, was seine Nützlichkeit für die langfristige Profilerstellung einschränkt.
Wie lange bleiben Daten in SessionStorage vs. LocalStorage?
localStorage-Daten bleiben erhalten, bis sie explizit gelöscht werden, entweder indem der Benutzer den Browser-Speicher löscht, die Website localStorage.removeItem() oder localStorage.clear() aufruft oder der Browser Speicherkontingente durchsetzt. [2]
sessionStorage-Daten werden automatisch gelöscht, wenn der Tab oder das Fenster, das sie erstellt hat, geschlossen wird. Sie überleben Seitenneuladungen innerhalb desselben Tabs, werden aber nicht auf neue Tabs übertragen, selbst wenn der Benutzer den Tab in einigen Browsern dupliziert. [1]
Praktische Implikation: Wenn ein Entwickler ein Sitzungstoken in localStorage anstelle von sessionStorage speichert, bleibt dieses Token auf dem Gerät, nachdem der Benutzer sich abgemeldet hat, es sei denn, die Anwendung entfernt es explizit. Dies ist ein häufiger und folgenschwerer Fehler.
Ist SessionStorage privater als localStorage?
Für die meisten Datenschutzanwendungsfälle ist sessionStorage die datenschutzfreundlichere Wahl. Die automatische Löschung beim Schließen des Tabs bedeutet, dass Daten nicht verbleiben, was das Risiko bei der Gerätenutzung durch mehrere Personen, gestohlenen Geräten oder forensischen Analysen reduziert.
Allerdings ist sessionStorage nicht von Natur aus "privat". Innerhalb einer aktiven Sitzung ist es genauso anfällig für XSS-Angriffe wie localStorage. Jedes injizierte Skript kann sessionStorage.getItem() aufrufen und Daten in Echtzeit exfiltrieren. [3]
Wählen Sie sessionStorage, wenn: die Daten nur für die aktuelle Benutzerinteraktion benötigt werden (z. B. mehrstufiger Formularstatus, einmalige Navigations-Token).
Wählen Sie localStorage, wenn: die Daten tatsächlich über Sitzungen hinweg bestehen bleiben müssen (z. B. Benutzer-UI-Einstellungen, nicht-sensible Einstellungen), und stellen Sie sicher, dass sie nichts persönlich Identifizierbares enthalten.
Welche persönlichen Daten sollten niemals in localStorage gespeichert werden?
Die folgenden Datenkategorien sollten niemals in localStorage gespeichert werden (und sollten selbst in sessionStorage mit äußerster Vorsicht behandelt werden): [3]
- Authentifizierungstoken (JWTs, OAuth-Token, Sitzungs-IDs)
- Passwörter oder Passwort-Hashes
- Kreditkarten- oder Zahlungsinformationen
- Von der Regierung ausgestellte Ausweisnummern oder Sozialversicherungsnummern
- Vollständige Namen in Kombination mit E-Mail-Adressen oder Telefonnummern
- Medizinische oder Gesundheitsdaten
- Alle Daten, die unter der DSGVO als "besondere Kategorie" eingestuft werden (biometrische Daten, Gesundheitsdaten, politische Meinungen)
Daten, die sowohl in localStorage als auch in sessionStorage gespeichert werden, sind standardmäßig unverschlüsselt. Jeder, der physischen Zugriff auf das Gerät hat oder jedes Skript, das auf der Seite ausgeführt werden kann, kann sie im Klartext lesen. [3]
Können Drittanbieter-Skripte auf localStorage-Daten zugreifen?
Drittanbieter-Skripte können auf localStorage-Daten zugreifen, wenn sie im selben Ursprung wie die Host-Seite geladen und ausgeführt werden. Dies ist ein kritisches und häufig unterschätztes Risiko.
Wenn eine Website ein Drittanbieter-Analyse- oder Werbeskript über ein <script>-Tag einbettet, läuft dieses Skript im Ursprungskontext der Host-Seite. Es kann frei auf das localStorage der Website lesen und schreiben. Die Same-Origin-Policy schützt nicht vor Skripten, die absichtlich oder unabsichtlich auf der Seite enthalten sind. [4]
Was dies in der Praxis bedeutet: Wenn eine Website einen Benutzeridentifikator in localStorage speichert und auch ein Drittanbieter-Werbeskript lädt, kann dieses Werbeskript den Identifikator lesen und ihn mit websiteübergreifenden Verhaltensdaten verknüpfen, ohne Wissen oder Zustimmung des Benutzers.
Dies ist ein Grund, warum Consent Management Platforms wichtig sind. Biscotti CMP ermöglicht es Websites, die Benutzerzustimmung für Speicheroperationen, einschließlich localStorage-basiertem Tracking, zu verwalten und zu dokumentieren, und hilft Websites, ihren Verpflichtungen gemäß der DSGVO und ähnlichen Rahmenwerken nachzukommen.
Welche DSGVO-Auswirkungen hat die Verwendung von localStorage?
Gemäß der DSGVO erfordert jede Speicherung personenbezogener Daten oder Tracking-Identifikatoren, unabhängig vom technischen Mechanismus, eine Rechtsgrundlage. Für nicht-essentielles Tracking über localStorage ist diese Grundlage fast immer die explizite Benutzerzustimmung. [2]
Der Europäische Datenschutzausschuss hat bestätigt, dass localStorage, das für Analysen, Werbung oder Benutzerprofilierung verwendet wird, denselben Zustimmungsanforderungen unterliegt wie Cookies. Websites, die Tracking-Identifikatoren ohne vorherige Zustimmung in localStorage ablegen, sind denselben Durchsetzungsrisiken ausgesetzt wie diejenigen, die nicht zugestimmte Cookies verwenden.
Compliance-Checkliste für localStorage unter der DSGVO:
- Überprüfen Sie alle localStorage-Schlüssel, die von Erstanbieter- und Drittanbieter-Skripten geschrieben wurden.
- Klassifizieren Sie jeden Schlüssel: Ist er unbedingt für den Dienst erforderlich oder wird er für Analysen/Werbung verwendet?
- Für nicht-essentiellen Speicher die Schreiboperation hinter einer dokumentierten Benutzerzustimmung verbergen.
- Bieten Sie Benutzern einen klaren Mechanismus zum Widerruf der Zustimmung und zur Auslösung der Speicherlöschung.
- Dokumentieren Sie das berechtigte Interesse des Datenverantwortlichen oder die Zustimmungsaufzeichnung.
Eine ordnungsgemäß konfigurierte Consent Management Platform wie Biscotti CMP kann einen Großteil dieses Zustimmungslebenszyklus automatisieren.
Kann auf localStorage über verschiedene Websites hinweg zugegriffen werden?
Nein. localStorage ist streng auf den Ursprung (Protokoll + Domain + Port-Kombination) beschränkt, der es erstellt hat. Ein Skript auf https://siteA.com kann keine localStorage-Daten lesen, die von https://siteB.com gesetzt wurden. [4]
Dieser Schutz hat jedoch Grenzen. Wenn ein einzelner Werbe- oder Analyseanbieter seine Skripte sowohl auf siteA.com als auch auf siteB.com lädt, schreibt jede Instanz unabhängig in das jeweilige localStorage der Website. Der Anbieter korreliert dann die Daten serverseitig und erreicht so effektiv websiteübergreifendes Tracking, ohne die Same-Origin-Policy zu verletzen.
Wie beeinflussen der Inkognito-Modus und privates Surfen localStorage?
Privates/Inkognito-Browsen erstellt eine temporäre Speicherpartition, die gelöscht wird, wenn das private Fenster geschlossen wird. localStorage, das während einer Inkognito-Sitzung geschrieben wird, bleibt nicht im Hauptbrowserprofil erhalten und ist für normale Browserfenster nicht zugänglich.
sessionStorage verhält sich im Inkognito-Modus genauso wie beim normalen Browsen: Es wird gelöscht, wenn der Tab geschlossen wird.
Wichtige Vorbehalte:
- Innerhalb einer aktiven Inkognito-Sitzung ist localStorage weiterhin von allen Skripten lesbar, die im Same-Origin-Kontext dieser Sitzung ausgeführt werden.
- Der Inkognito-Modus verhindert keine Echtzeit-XSS-basierte Datenexfiltration.
- Einige Browser synchronisieren localStorage über Geräte hinweg, wenn der Benutzer bei der Browser-Synchronisierung angemeldet ist, ein Verhalten, das "lokale" Daten in die Cloud-Infrastruktur verschieben kann.
Wie lösche ich SessionStorage und localStorage zum Schutz der Privatsphäre?
Das Löschen des Browser-Speichers ist unkompliziert, erfordert aber eine bewusste Handlung, da Browser dies für localStorage nicht automatisch tun.
Browser-weites Löschen:
- Chrome: Einstellungen > Datenschutz und Sicherheit > Browserdaten löschen > Zwischengespeicherte Bilder und Dateien + Website-Daten
- Firefox: Einstellungen > Datenschutz & Sicherheit > Cookies und Website-Daten > Daten löschen
- Safari: Einstellungen > Datenschutz > Website-Daten verwalten
Programmatisches Löschen (für Entwickler):
localStorage.clear()entfernt alle Schlüssel für den Ursprung.sessionStorage.clear()entfernt alle Schlüssel für die aktuelle Tab-Sitzung.localStorage.removeItem('keyName')entfernt einen bestimmten Schlüssel.
Für Endbenutzer, die sich um Tracking sorgen: Das Löschen von "Website-Daten" oder "Cookies und Speicher" in den Browser-Einstellungen entfernt sowohl localStorage- als auch sessionStorage-Inhalte für alle Websites. Browser-Erweiterungen, die für den Datenschutz entwickelt wurden, können dies pro Website oder pro Sitzung automatisieren.
Was sind häufige Datenschutzfehler, die Entwickler bei Web Storage machen?
Die folgenreichsten Fehler haben eine gemeinsame Wurzel: die Behandlung von clientseitigem Speicher, als wäre er eine sichere serverseitige Datenbank.
- Speichern von JWTs in localStorage: Authentifizierungstoken, die in localStorage gespeichert sind, sind für jedes Skript auf der Seite zugänglich. Eine einzige XSS-Schwachstelle legt das Token jedes Benutzers offen. Verwenden Sie stattdessen HttpOnly-Cookies für Authentifizierungstoken.
- Keine Ablauflogik: localStorage hat keine TTL. Entwickler, die Daten ohne Ablauflogik speichern, hinterlassen veraltete, sensible Daten unbegrenzt auf Geräten.
- Annahme, dass Same-Origin sicher ist: Die Same-Origin-Policy blockiert externe Websites, nicht bösartige Skripte, die von derselben Website geladen werden (XSS, kompromittierte Drittanbieter-Bibliotheken).
- Ignorieren des Zugriffs von Drittanbieter-Skripten: Einbetten von Analyse- oder Werbeskripten, ohne zu überprüfen, was sie aus localStorage lesen.
- Keine Zustimmungsbarriere für Tracking-Speicher: Schreiben von Analyse-Identifikatoren in localStorage, bevor die Benutzerzustimmung eingeholt wird, ein direkter DSGVO-Verstoß. [2]
- Speichern redundanter PII: Zwischenspeichern von API-Antworten, die vollständige Benutzerprofile in localStorage enthalten, "zur Leistungssteigerung", ohne die Angriffsfläche zu berücksichtigen.
Ist IndexedDB privater als localStorage?
IndexedDB ist nicht von Natur aus privater als localStorage. Beide unterliegen der Same-Origin-Policy, beide sind für JavaScript, das auf der Seite ausgeführt wird, zugänglich und beide sind anfällig für XSS-Angriffe.
IndexedDB bietet eine größere Speicherkapazität und unterstützt strukturierte Daten und binäre Blobs, wodurch es für komplexe Offline-Anwendungen geeignet ist. Aus Datenschutz- und Sicherheitssicht sind die Risiken jedoch vergleichbar. Daten, die in IndexedDB gespeichert sind, sind standardmäßig ebenfalls unverschlüsselt und bleiben unbegrenzt erhalten, es sei denn, sie werden explizit gelöscht.
Die Wahl zwischen IndexedDB und localStorage sollte von der Datenkomplexität und den Volumenanforderungen bestimmt werden, nicht von Datenschutzannahmen. Keines von beiden ist für sensible persönliche Daten ohne anwendungsschichtige Verschlüsselung und strenge Zugriffskontrollen geeignet.
Fazit
Die Debatte SessionStorage vs. LocalStorage: Auswirkungen auf den Datenschutz von Web Storage APIs ist nicht nur eine technische Fußnote, sie hat direkte Konsequenzen für den Datenschutz der Benutzer, die Einhaltung gesetzlicher Vorschriften und die Anwendungssicherheit. Die unbegrenzte Persistenz und die tabübergreifende Zugänglichkeit von localStorage machen es zu einem Hochrisiko-Speichermechanismus, wenn es missbraucht wird, während die automatische Löschung von sessionStorage beim Schließen des Tabs es zur verteidigungsfähigeren Wahl für temporäre Zustände macht.
Umsetzbare nächste Schritte für Entwickler und Website-Betreiber im Jahr 2026:
- Überprüfen Sie alle localStorage- und sessionStorage-Nutzungen über Erstanbieter- und Drittanbieter-Skripte mithilfe der Browser-Entwicklertools (Registerkarte "Anwendung").
- Entfernen Sie sofort alle Authentifizierungstoken, PII oder sensiblen Identifikatoren aus dem clientseitigen Speicher.
- Ersetzen Sie die localStorage-basierte Speicherung von Authentifizierungstoken durch HttpOnly-, Secure-Cookies, die serverseitig verwaltet werden.
- Implementieren Sie einen Workflow für das Einwilligungsmanagement, z. B. mit einer Plattform wie Biscotti CMP, um nicht-essentielle localStorage-Schreibvorgänge hinter einer dokumentierten Benutzerzustimmung zu verbergen.
- Bauen Sie eine Ablauflogik in alle localStorage-Daten ein, die bestehen bleiben müssen, und erzwingen Sie die Bereinigung beim Abmelden.
- Führen Sie eine Überprüfung von Drittanbieter-Skripten durch, um zu verstehen, welche externen Codes aus dem Speicher Ihres Ursprungs lesen können.
- Schulen Sie Entwicklungsteams in der XSS-Prävention als primärem Angriffsvektor gegen beide Speichertypen.
Web Storage APIs sind leistungsstarke Tools. Ohne Datenschutzdisziplin werden sie zu Haftungsvektoren. Mit bewusster Bereichsdefinition, Einwilligungsmanagement und Sicherheitshygiene erfüllen sie ihren beabsichtigten Zweck, ohne die Benutzer zu gefährden, die Ihrer Anwendung vertrauen.
FAQ
F: Was ist der Hauptunterschied zwischen sessionStorage und localStorage? localStorage speichert Daten unbegrenzt über Sitzungen hinweg und wird über alle Tabs desselben Ursprungs geteilt. sessionStorage speichert Daten nur für die Lebensdauer des aktuellen Tabs und wird automatisch gelöscht, wenn der Tab geschlossen wird.
F: Kann localStorage verwendet werden, um Benutzer ohne Cookies zu verfolgen? Ja. Ein eindeutiger Identifikator, der in localStorage gespeichert ist, überlebt die Cookie-Löschung und kann verwendet werden, um Benutzer über mehrere Besuche derselben Website hinweg zu verfolgen, wodurch er als persistenter Tracking-Mechanismus fungiert.
F: Ist sessionStorage sicher zum Speichern von Passwörtern? Nein. sessionStorage ist nicht verschlüsselt und für jedes JavaScript auf der Seite zugänglich, einschließlich injizierter bösartiger Skripte. Passwörter sollten niemals in einem clientseitigen Speichermechanismus gespeichert werden.
F: Gilt die DSGVO für localStorage? Ja. Gemäß der DSGVO ist das Speichern von Tracking-Identifikatoren oder personenbezogenen Daten in localStorage ohne eine Rechtsgrundlage, typischerweise die explizite Benutzerzustimmung für nicht-essentielle Zwecke, ein Verstoß gegen die Compliance, der der Verwendung von Cookies ohne Zustimmung gleichkommt.
F: Können Drittanbieter-Skripte meine localStorage-Daten lesen?
Ja, wenn diese Skripte innerhalb desselben Ursprungs geladen und ausgeführt werden. Drittanbieter-Analyse- oder Werbeskripte, die über <script>-Tags eingebettet sind, laufen im Ursprungskontext der Host-Seite und können alle localStorage-Daten für diesen Ursprung lesen.
F: Löscht das Löschen von Cookies auch localStorage? Nicht immer. In den meisten Browsern löscht das alleinige Löschen von "Cookies" localStorage nicht. Benutzer müssen explizit "Website-Daten" oder "Cookies und andere Website-Daten" löschen, um localStorage-Inhalte zu entfernen.
F: Ist der Inkognito-Modus sicher vor localStorage-Tracking? Der Inkognito-Modus verhindert, dass localStorage-Daten nach dem Schließen des privaten Fensters bestehen bleiben, aber innerhalb einer aktiven Inkognito-Sitzung ist localStorage weiterhin von allen Skripten auf der Seite lesbar.
F: Was sollte ich anstelle von localStorage für Authentifizierungstoken verwenden? Verwenden Sie HttpOnly-, Secure-, SameSite-Cookies, die serverseitig verwaltet werden. Diese Cookies sind für JavaScript unzugänglich, wodurch das XSS-basierte Token-Diebstahlrisiko, das localStorage birgt, eliminiert wird.
F: Ist IndexedDB sicherer als localStorage? Nein. IndexedDB unterliegt denselben XSS-Schwachstellen und der Same-Origin-Policy wie localStorage. Es bietet eine größere Kapazität und Unterstützung für Datenstrukturen, aber keine zusätzlichen Datenschutz- oder Sicherheitsgarantien.
F: Wie viele Daten können localStorage und sessionStorage speichern? Die meisten modernen Browser weisen pro Ursprung etwa 5 bis 10 MB Speicherplatz für jeden Speichertyp zu, deutlich mehr als die typische 4-KB-Grenze von Cookies. [2]
Referenzen
[1] Sessionstorage - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai
[2] What Is Localstorage Sessionstorage - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai
[3] Html5 Web Storage Security Risks Safeguarding Localstorage And Sessionstorage - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai
[4] Localstorage - https://javascript.info/localstorage?utm_source=openai
[5] Localstorage Sessionstorage - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai
[6] Cookies Vs Localstorage Vs Sessionstorage What Each One Exactly Means - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai