Local Storage

Ganz einfach mit JavaScript:

// Speichern
localStorage.setItem('theme', 'dark');

// Lesen
const theme = localStorage.getItem('theme'); // 'dark'

// Löschen
localStorage.removeItem('theme');

Daten bleiben erhalten, auch wenn der Browser geschlossen wird.

1. Das XSS-Risiko (JWTs)

Viele Entwickler speichern Security Tokens (JWT) im Local Storage. Tödlicher Fehler. Local Storage ist per Design von jedem JavaScript auf der Seite lesbar. Wenn du eine XSS-Lücke hast (oder eine böse npm-Library), liest der Hacker: localStorage.getItem('token') -> und schickt es an seinen Server. Account weg. Sensitive Daten gehören in HttpOnly Cookies, nicht in Local Storage!

2. Sync & String Only

• Nur Strings: Du kannst keine Objekte speichern. Musst JSON.stringify() und JSON.parse() nutzen. Das kostet Performance auf dem Main Thread.
• Synchron: Local Storage blockiert den Main Thread. Wenn du 5MB liest, friert die Seite kurz ein. Für große Daten lieber IndexedDB (Asynchron) nutzen.

3. SessionStorage

Der kleine Bruder. Funktioniert exakt gleich, aber: Daten werden gelöscht, sobald der Tab geschlossen wird. Gut für sensible Daten, die nicht auf dem PC bleiben sollen (z. B. Formulardaten eines mehrseitigen Wizards), oder wenn User zwei Tabs offen hat und unterschiedliche Zustände braucht.

1. Same-Origin Policy (SOP) Boundaries

LocalStorage ist gnadenlos an den Origin gebunden (Protokoll + Domain + Port). Eine Webseite auf https://app.com hat physikalisch Null Zugriff auf den Storage von https://blog.app.com (Subdomain Tausch) oder http://app.com (Downgrade). Dieses Sandboxing macht "Single Sign-On (SSO)" zwischen unterschiedlichen Domains extrem komplex. Architektonischer Workaround (Cross-Origin Messaging): Domain A bettet ein unsichtbares <iframe> von Domain B ein. Domain A nutzt postMessage(), sendet das Token in den iFrame (B), welcher dann in den isolierten LocalStorage von Domain B schreiben darf. (Achtung, drittanbieter-Cookie Blockaden Safari (ITP) zerschießen dieses Pattern heute oft!).

2. Event Listener Synchronization (Multi-Tab)

Viele SPAs (React/Vue) managen Caches im RAM (Redux Store). Has der User den Shop in drei Tabs geöffnet, und loggt sich in Tab 1 aus, existiert der Token im RAM der Tabs 2+3 fröhlich weiter. Der Trick: Browser werfen beim setItem / removeItem ein magisches storage Event am window-Objekt ab – aber nur in allen anderen parallelen Tabs derselben Origin, nicht im Tab, der den Storage modifizierte! Ein Listener (window.addEventListener('storage', e => { if(e.key === 'token') logout() })) fängt das auf und erzwingt das purgen der Memory-Stores über alle offenen Tab-Grenzen hinweg synchron.

3. I/O Blocking and IndexedDB (Performance Crash)

Die Browser API ist fatalerweise synchron implementiert. Liest du eine 5MB Base64-Image Kette per localStorage.getItem("cache"), blockiert die JS-Engine eiskalt den Main-Event-Thread für bis zu 50 Millisekunden. Die UI stottert, Button-Klicks freezen, 60 FPS Raten brechen ein. Modernes Web nutzt für nennenswerte Payload-Mengen heute IndexedDB oder Wrapper (localForage). IndexedDB speichert Binary-Blobs lokal, operiert strikt asynchron via Promises, unterstützt Multi-Index-Suchen auf Datenbank-Ebene und crasht den Render-Strand nicht.