Cookies vs localStorage vs sessionStorage: Client Storage

Beim Erstellen einer Webanwendung müssen Sie häufig Daten auf der Client-Seite speichern – sei es die Theme-Einstellung eines Benutzers, ein Warenkorb oder ein Authentifizierungs-Token. Die drei Hauptoptionen sind Cookies, localStorage und sessionStorage. Jede hat unterschiedliche Eigenschaften, die sie für verschiedene Szenarien geeignet machen. Die falsche Wahl kann zu Sicherheitslücken, Leistungsproblemen oder einer schlechten Benutzererfahrung führen.

Dieser Artikel erläutert die Unterschiede, bietet praktische Anleitungen und hilft Ihnen zu entscheiden, welchen Speichermechanismus Sie für Ihr nächstes Projekt verwenden sollten.

Schneller Vergleich

Bevor wir ins Detail gehen, hier ein Überblick über die drei Speichertypen:

Cookies: Der ursprüngliche Client-Speicher

Cookies gibt es seit den Anfängen des Webs. Sie sind kleine Datenstücke (max. ~4KB), die der Browser speichert und automatisch bei jeder HTTP-Anfrage an dieselbe Domain an den Server sendet.

Wann Cookies verwendet werden sollten

• Authentifizierungssitzungen: Speichern Sie Sitzungs-IDs oder Token, die der Server bei jeder Anfrage validieren muss. Verwenden Sie die Flags HttpOnly, Secure und SameSite, um XSS- und CSRF-Risiken zu mindern.
• Serverseitige Personalisierung: Wenn der Server Benutzereinstellungen (z. B. Sprache, Theme) kennen muss, bevor die Seite gerendert wird.
• Tracking und Analyse: Cookies können sitzungsübergreifend bestehen bleiben und bei entsprechender Konfiguration über Subdomains hinweg geteilt werden.

Sicherheitsüberlegungen

Cookies werden automatisch gesendet, was sie anfällig für CSRF macht, wenn sie ohne zusätzliche Schutzmaßnahmen zur Authentifizierung verwendet werden. Setzen Sie immer das SameSite-Attribut (Lax oder Strict) und ziehen Sie die Verwendung von CSRF-Token in Betracht. Verwenden Sie für sensible Daten HttpOnly, um den JavaScript-Zugriff zu verhindern und die Auswirkungen von XSS zu reduzieren.

Beispiel für das Setzen eines sicheren Cookies in einer HTTP-Antwort:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

localStorage: Persistenter Key-Value-Speicher

localStorage bietet einen einfachen Key-Value-Speicher, der auch nach dem Schließen des Browsers erhalten bleibt. Die Daten werden pro Origin (Protokoll + Domain + Port) gespeichert und nicht automatisch an den Server gesendet. Es ist ideal für die Speicherung nicht sensibler Daten, die Seitenneuladungen und Browser-Neustarts überstehen sollen.

Wann localStorage verwendet werden sollte

• Benutzereinstellungen: Theme (Dunkel/Hell), Schriftgröße, Sprache oder Layout-Einstellungen.
• Caching: Speichern Sie API-Antworten oder statische Daten, um Netzwerkanfragen zu reduzieren und die Offline-Erfahrung zu verbessern.
• Clientseitiger Zustand: Warenkorbinhalte, Entwurfsformulardaten oder Feature-Flags.

Sicherheitsüberlegungen

localStorage ist über JavaScript zugänglich, sodass jede XSS-Schwachstelle alle gespeicherten Daten offenlegen kann. Speichern Sie niemals sensible Informationen wie Passwörter, persönliche Identifikationsnummern oder Authentifizierungs-Token, es sei denn, Sie haben robuste XSS-Schutzmaßnahmen implementiert. Wenn Sie Token speichern müssen, ziehen Sie stattdessen den HttpOnly-Cookie-Ansatz in Betracht.

Beispiel für die Verwendung von localStorage:

// Benutzereinstellung speichern
localStorage.setItem('theme', 'dark');

// Einstellung abrufen
const theme = localStorage.getItem('theme');

// Element entfernen
localStorage.removeItem('theme');

sessionStorage: Speicher pro Tab

sessionStorage ähnelt localStorage, hat aber eine kürzere Lebensdauer: Die Daten werden gelöscht, wenn der Tab oder das Fenster geschlossen wird. Es ist auf einen einzelnen Tab beschränkt, sodass Daten nicht zwischen Tabs oder Fenstern geteilt werden, auch nicht für dieselbe Origin.

Wann sessionStorage verwendet werden sollte

• Mehrstufige Formulare: Speichern Sie Formulardaten vorübergehend, während der Benutzer die Schritte durchläuft, ohne dass sie nach Abschluss bestehen bleiben.
• Zustand pro Tab: Daten, die nicht zwischen Tabs gelangen sollen, wie ein temporärer Authentifizierungszustand oder ein Einmal-Token.
• Sensible Vorgänge: Wenn Sie möchten, dass Daten automatisch gelöscht werden, wenn der Benutzer den Tab schließt, um die Exposition zu verringern.

Sicherheitsüberlegungen

Wie localStorage ist auch sessionStorage anfällig für XSS. Seine begrenzte Lebensdauer und der Geltungsbereich pro Tab verringern jedoch das Zeitfenster für Angreifer. Vermeiden Sie dennoch die Speicherung hochsensibler Daten.

Beispiel für die Verwendung von sessionStorage:

// Formulardaten speichern
sessionStorage.setItem('formStep1', JSON.stringify({name: 'John'}));

// Formulardaten abrufen
const step1 = JSON.parse(sessionStorage.getItem('formStep1'));

Wie wählen: Ein Entscheidungsleitfaden

Verwenden Sie die folgende geordnete Liste, um Ihre Entscheidung zu leiten:

1. Muss der Server die Daten bei jeder Anfrage lesen? Wenn ja, verwenden Sie Cookies. Beispiel: Sitzungs-IDs.
2. Müssen die Daten über Browsersitzungen hinweg bestehen bleiben? Wenn ja, verwenden Sie localStorage. Beispiel: Benutzereinstellungen.
3. Sollen die Daten auf einen einzelnen Tab beschränkt sein? Wenn ja, verwenden Sie sessionStorage. Beispiel: Daten aus mehrstufigen Formularen.
4. Sind die Daten sensibel? Vermeiden Sie die Speicherung in localStorage oder sessionStorage. Verwenden Sie HttpOnly-Cookies für Token und speichern Sie niemals Passwörter.
5. Sind die Daten groß? Cookies sind auf ~4KB begrenzt; localStorage und sessionStorage bieten viel mehr Kapazität.

Sicherheits-Best Practices

• Validieren und bereinigen Sie Eingaben immer, um XSS zu verhindern, das jeden clientseitigen Speicher kompromittieren kann.
• Verwenden Sie HttpOnly-, Secure- und SameSite-Cookies für Authentifizierungs-Token, um XSS und CSRF zu mindern.
• Vermeiden Sie die Speicherung sensibler Daten in localStorage oder sessionStorage. Wenn es sein muss, verschlüsseln Sie sie und verwenden Sie kurze Ablaufzeiten.
• Implementieren Sie eine Content Security Policy (CSP), um XSS-Risiken zu reduzieren.
• Löschen Sie regelmäßig veraltete Daten, um Speichergrenzen nicht zu überschreiten und die Exposition zu verringern.

FAQ

Kann ich localStorage für Authentifizierungs-Token verwenden?

Es wird nicht empfohlen, da localStorage über JavaScript zugänglich ist und Token dadurch anfällig für XSS sind. Bevorzugen Sie HttpOnly-Cookies mit Secure- und SameSite-Flags.

Was passiert mit sessionStorage, wenn ich einen Tab dupliziere?

Wenn Sie einen Tab duplizieren, erhält der neue Tab eine Kopie des sessionStorage des ursprünglichen Tabs zum Zeitpunkt der Duplizierung. Danach sind sie unabhängig.

Werden Cookies bei jeder Anfrage an den Server gesendet?

Ja, Cookies für die aktuelle Domain werden automatisch in jede HTTP-Anfrage aufgenommen, was die Leistung beeinträchtigen kann, wenn Sie zu viele Daten speichern. Verwenden Sie sie sparsam.

Müssen Sie JSON-Daten, die Sie speichern, schnell formatieren oder validieren? Probieren Sie unseren JSON Formatter, um Ihre JSON-Payloads zu verschönern und zu debuggen, bevor Sie sie im Client-Speicher speichern.