flawopen.com/Referenz/JWT vs. HttpOnly-Cookies
JWT im localStorage vs. HttpOnly-Cookies: Was ist sicherer?
Für viele Webanwendungen ist eine serverseitig verwaltete Sitzung in einem HttpOnly-Cookie ein guter Ausgangspunkt. JavaScript kann dieses Cookie nicht lesen, was das Auslesen des Tokens erschwert, XSS aber nicht neutralisiert: Eingeschleuster Code derselben Origin kann weiterhin authentifizierte Anfragen senden und für die Seite erreichbare Daten lesen.
Die Sicherheitsabwägungen
| Speicherung / Übertragung | XSS-Risiko | CSRF-Verhalten | Widerruf |
|---|---|---|---|
localStorage bearer token | JavaScript derselben Origin kann es lesen; XSS kann es stehlen oder als Nutzer handeln. | Wird Cross-Site-Anfragen nicht automatisch hinzugefügt; XSS und clientseitiges CSRF bleiben Risiken. | Ein selbstständiges JWT kann bis zum Ablauf gültig bleiben, wenn kein Widerruf geprüft wird. |
HttpOnly cookie | JavaScript kann den Wert nicht lesen; XSS kann dennoch authentifizierte Anfragen senden. | Wird nach Cookie-Regeln automatisch gesendet; SameSite ist nur eine CSRF-Schutzschicht. | Eine undurchsichtige Sitzung ist serverseitig invalidierbar; ein JWT-Cookie braucht eine eigene Widerrufsregel. |
Empfohlene Architektur
- ✓Speichern Sie Sitzungs-IDs in
HttpOnly; Secure; SameSite=Lax-Cookies. - ✓Vermeiden Sie es, dauerhafte Authentifizierungstokens in
localStorageodersessionStoragezu speichern.
Tokenformat, Speicherort und Sitzungszustand unterscheiden
JWT ist ein Tokenformat; localStorage und Cookies sind Speicher- und Übertragungswege des Browsers. Ein JWT kann in beiden gespeichert werden. Eine undurchsichtige Sitzungskennung im Cookie verweist üblicherweise auf serverseitigen Zustand. „JWT oder Cookie“ ist kein direkter Vergleich gleichartiger Alternativen.
Was die jeweilige Wahl verändert
Der Browser fügt localStorage-Werte nicht automatisch zu Cross-Site-Anfragen hinzu; XSS derselben Origin kann ein Bearer-Token dennoch auslesen oder über die Anwendung handeln. Cookies werden nach Browserregeln gesendet; HttpOnly verbirgt den Wert vor JavaScript, hindert eingeschleusten Code aber nicht daran, die angemeldete Seite zu verwenden. SameSite=Lax ist eine CSRF-Schutzschicht, keine vollständige Garantie: sichere Top-Level-Navigationen und Same-Site-Anfragen bleiben relevant. Ändere keinen Zustand per GET und nutze passende CSRF-Kontrollen, etwa validierte Tokens und/oder Origin-Prüfungen.
Widerruf hängt von Serverzustand und Tokenprüfung ab, nicht vom Speicherort. Eine serverseitige Sitzung lässt sich durch Löschen ihres Eintrags invalidieren. Ein selbstständiges JWT kann bis zum Ablauf akzeptiert werden, wenn kein Widerruf geprüft wird; kurze Laufzeiten verkleinern das Fenster, beseitigen es aber nicht.
Praktischer Ausgangspunkt
- ✓Bevorzuge bei einer eigenen Webanwendung eine undurchsichtige serverseitige Sitzung oder, falls passend, ein Backend-for-Frontend (BFF).
- ✓Setze Sitzungscookies mit
Secure,HttpOnly, bewusst gewähltemSameSite,Path=/und möglichst ohneDomain; erwäge__Host-. - ✓Nutze für zustandsändernde Anfragen passende CSRF-Tokens und/oder Origin-Prüfungen; ändere niemals Zustand per
GET. - ✓Wenn JWTs im Browser nötig sind, begrenze ihre Laufzeit, definiere Logout und Widerruf und verhindere XSS. Ein Cookie ersetzt keine Autorisierungsprüfung.