Stop Storing JWTs in localStorage. Here's Why.

Many tutorials suggest storing JWTs in localStorage when implementing authentication. It seems straightforward: save the authentication token and include it with each API request. However, this approach has a significant flaw. Any script running on your webpage can access this token, including malicious JavaScript. If your site has an XSS vulnerability, an attacker could steal the token and gain access to the user's account until it expires or is revoked.

This risk isn't specific to JWTs; any sensitive data stored in localStorage is vulnerable. A better solution is to use HttpOnly cookies instead of localStorage. Set-Cookie headers can help secure these cookies by limiting access to JavaScript. HttpOnly means JavaScript can't read the cookie, Secure ensures the browser only sends it over HTTPS, and SameSite=Strict prevents cross-site requests from sending the cookie.

This way, even if an attacker exploits XSS, they can't access the HttpOnly cookies. However, HttpOnly cookies aren't foolproof. Malicious JavaScript can still send authenticated requests, and CSRF attacks can still occur. To mitigate CSRF risks, implement proper protections like validating request origins, using SameSite cookies, and adding CSRF tokens where necessary.

The double-submit cookie pattern, where the server validates a CSRF token with each request, is a common approach. Additionally, using short-lived JWTs and rotating signing keys securely is crucial. By issuing tokens with limited lifetimes and carefully managing key rotation, you can minimize the impact of potential compromises.

While localStorage can still be used for non-sensitive settings, JWTs for authentication should be stored securely using HttpOnly cookies. Authentication is about more than just login; it requires careful consideration of how tokens are stored, protected, and revoked when needed.