JavaScript: Wann nutzt man Cookies, wann die Storage-API?
Ob du Cookies oder die Web Storage API (also localStorage
/ sessionStorage
) verwenden solltest, hängt vom Zweck ab. Beide haben unterschiedliche Einsatzzwecke, Vorteile und Einschränkungen.
🔒 Cookies – Wann verwenden?
Geeignet für:
- Daten, die an den Server gesendet werden sollen (z. B. für Authentifizierung)
- Tracking über verschiedene Seiten (z. B. Login, Session-ID)
- Serverseitige Logik, die auf Cookie-Daten angewiesen ist
Eigenschaften:
- Werden bei jedem HTTP-Request automatisch mitgeschickt
- Max. ~4 KB pro Cookie
- Verfallsdatum steuerbar (
expires
,max-age
) - Können HTTP-only sein (für mehr Sicherheit, nicht aus JS lesbar)
Nachteile:
- Klein, unübersichtlich, nicht für komplexe Daten
- DSGVO-relevant (müssen evtl. abgefragt werden)
- Performance-Nachteil bei vielen Cookies, da sie immer mitgesendet werden
📦 Web Storage API – Wann verwenden?
Geeignet für:
- Daten, die nur im Client benötigt werden (z. B. UI-Einstellungen, Caches)
- Daten, die nicht mit jedem Request an den Server gehen sollen
- Größere Datenmengen (bis zu 5–10 MB je nach Browser)
Eigenschaften:
localStorage
: bleibt erhalten, auch nach einem Browser-NeustartsessionStorage
: nur während der aktuellen Tab-Sitzung verfügbar- Einfacher zu bedienen (Key-Value-Speicher)
- Kein automatisches Senden an den Server
Nachteile:
- Kein Schutz vor JavaScript-Zugriff → sicherheitsrelevant
- Keine Serverkommunikation (außer du baust sie selbst)
📌 Kurzfazit:
Aufgabe | Empfehlung |
---|---|
Authentifizierung (Token, Session) | ✅ Cookies (evtl. HTTP-only, Secure) |
Temporäre UI-Daten, Caches | ✅ sessionStorage / localStorage |
Offline-Daten oder Preferences | ✅ localStorage |
Tracking & Analytics | Cookies (aber rechtlich bedenklich) oder Storage mit Consent |
Empfehlung für moderne Web-Apps:
- Nutze
localStorage
odersessionStorage
für Client-seitige Daten - Nutze Cookies nur, wenn du sie wirklich für serverseitige Dinge brauchst – vor allem, wenn du sie mit
HttpOnly
undSecure
nutzt