The Problem with Storing Tokens in localStorage/sessionStorage
Many modern web applications use JSON Web Tokens (JWTs) for authentication, often storing them in localStorage or sessionStorage for easy access. While this approach is simple, it introduces serious security risks:
Vulnerable to XSS Attacks Since localStorage and sessionStorage are accessible via JavaScript, any malicious script running on the page (e.g., from a compromised third-party library or browser extension) can steal tokens. Unlike httpOnly cookies, there’s no built-in protection against token theft via Cross-Site Scripting (XSS).
No Automatic Expiry Management Unlike cookies, which support Max-Age and Expires attributes, localStorage persists until explicitly cleared. If an attacker steals a token, they can use it indefinitely unless the server implements token revocation (which JWTs typically lack).
CSRF Risks When Falling Back to Cookies Some developers try to mitigate XSS by storing JWTs in cookies instead, but this introduces Cross-Site Request Forgery (CSRF) risks unless proper defenses (like SameSite=Strict and CSRF tokens) are implemented.
A Secure Alternative: The BFF (Backend-for-Frontend) Pattern
To avoid these risks, modern applications use a Backend-for-Frontend (BFF) layer combined with server-side token storage (Redis). Here’s how it works:
Tokens Stay on the Server The frontend never sees raw JWTs. Instead, it receives an httpOnly cookie containing only a session ID.
The actual access token and refresh token are stored securely in Redis (or another fast database).
How Authentication Flows Work Login: The BFF validates credentials, generates tokens, stores them in Redis, and sets an httpOnly cookie.
API Requests: The frontend sends the session cookie; the BFF retrieves the access token from Redis and forwards it to APIs.
Token Refresh: When the access token expires, the BFF uses the refresh token (stored in Redis) to get a new one—silently, without user interruption.
Logout: The BFF deletes the Redis entry, invalidating the session.
Why Redis? Speed: Token validation requires sub-millisecond response times (hard to achieve with traditional databases).
Auto-Expiry: Redis supports TTL (Time-To-Live), automatically cleaning up expired sessions.
Revocability: Unlike stateless JWTs, refresh tokens in Redis can be instantly revoked by deletion.
Key Benefits of This Approach ✅ Eliminates XSS Risks Since tokens are never exposed to the frontend, malicious JavaScript can’t steal them.
✅ Better Session Management Short-lived access tokens (15 minutes) minimize damage if leaked.
Long-lived refresh tokens (7 days) provide a seamless user experience.
✅ Scalable &amp; Performant Redis handles millions of token validations per second, making it ideal for high-traffic apps.
The BFF acts as a single point of control, simplifying microservice communication.
When Should You Use This? This pattern is ideal for:
SPAs (React, Angular, Vue) needing secure auth.
Mobile apps where token theft is a concern.
Microservices architectures where APIs shouldn’t handle cookies.
Final Thoughts While localStorage seems convenient, it’s a security anti-pattern for token storage. By moving tokens to a BFF + Redis backend, you get:
Stronger security (XSS/CSRF-resistant).
Better UX (silent refreshes, instant logouts).
Easier scalability (stateless JWTs + Redis performance).
Next Steps:
Implement httpOnly + Secure + SameSite cookies.
Set up Redis with persistence (RDB/AOF) to survive restarts.
Consider token binding (e.g., IP/device fingerprints) for extra security.

Heart

Building for the web? You're in the right place. This squad was created so anyone can share anything about web . Post your finds, drop a comment, and upvote great content to support the community! 🚀

WebCraft

The Backend-for-Frontend (BFF) pattern addresses security risks in web applications by storing JWTs server-side in Redis, eliminating exposure to XSS attacks and enhancing session management. This pattern is particularly suited to SPAs and mobile apps, offering improved scalability and user experience with silent token refreshes and instant logouts.

The Backend-for-Frontend (BFF) Pattern: Secure Auth Done Right

Great explanation, thanks for sharing!

cant the hacker steals the sessID ? i think the main problem still stays there, Am i wrong?

I have recently used this approach in nextjs recently as some of you might know you have to expose your tokens in next-auth if to be used on client side. I made an API route which serves as a proxy between my frontend and backend.