JWTs sind hier nicht das eigentliche Argument. Die Strategie für die Speicherung im Browser ist entscheidend. Teams speichern häufig Zugriffstoken in localStorage, weil dies aus dem Client-Code einfach zu implementieren ist. Das Problem ist einfach: Wenn XSS aktiv wird, ist das Token in der Regel sofort lesbar.
HttpOnly-Cookies verändern dieses Risikoprofil. Der Browser kann das Sitzungstoken automatisch senden, aber normales JavaScript kann es nicht zurücklesen.
Warum Cookies normalerweise sicherer im Browser sind
Ein sicheres Sitzungscookie sieht oft so aus:
Set-Cookie: session=opaque-token; HttpOnly; Secure; SameSite=Lax; Path=/
Das macht das System nicht unverwundbar. Es entfernt jedoch einen der einfachsten Wege zur Token-Exfiltration in Browseranwendungen.
Die Kompromisse, die Sie weiterhin beachten müssen
Das Verschieben des Tokens in ein Cookie ändert das Bedrohungsmodell, nicht den Bedarf an Sicherheitsmaßnahmen:
- CSRF-Abwehr ist nach wie vor wichtig
- Sitzungsrotation ist weiterhin wichtig
- XSS bleibt ein ernstes Problem, da ein Angreifer über die Seite handeln kann, auch wenn er das Token nicht lesen kann
Der Punkt ist nicht "Cookies lösen Authentifizierung". Der Punkt ist, dass die vom Browser verwaltete Sitzungstransportierung normalerweise sicherer ist, als Bearer-Tokens an localStorage zu übergeben.
Bessere Regel
Für browserbasierte Anwendungen sollten Sie in der Regel auf HttpOnly-Cookies zurückgreifen, es sei denn, Sie haben einen starken Grund, dies nicht zu tun. Greifen Sie nur dann auf Token-in-JavaScript-Designs zurück, wenn die Client-Architektur sie wirklich erfordert und der Sicherheitskompromiss verstanden wird.
Weiterführende Literatur