Hey everyone,
I've been working hard on an application for a client for about eight months, and we're nearing the launch date. I developed the app entirely by myself, utilizing my background in computer science and relying heavily on research and online resources. As this is one of my biggest projects yet, I'm starting to feel anxious about its security. While I have around three years of software development experience, most of my past projects have been internal tools or CMS systems.
The tech stack includes FastAPI for the backend, MySQL for the database, and React with ShadCN for the frontend. My main concern is the security of the app, which is a single-page application (SPA) allowing multi-account functionality. Here's how the authentication process works:
- Users log in via the frontend.
- The backend generates an access token and a refresh token.
- Access tokens are saved in session storage, and refresh tokens in local storage.
- Account data, including tokens, are stored as an array in local storage.
- Access tokens expire after 15 minutes.
- Refresh tokens last for 30 days, with a rotation mechanism in place. If someone tries to reuse an old refresh token, all user sessions are invalidated.
- I'm also planning to implement a strict Content Security Policy (CSP) to mitigate XSS risks due to the tokens being in local storage.
Despite this, I've been reading that using local storage for tokens is generally seen as risky. However, switching to secure HTTP-only cookies for multiple accounts seems complicated and could fundamentally alter the app's structure, which is mostly finalized now. So, is my security setup good enough, or should I spend more time reworking it? I'm really stressing over this!
4 Answers
Your current setup is reasonably secure for most applications. Implementing refresh token rotation and invalidation on reuse is a strong strategy, and a strict CSP will help mitigate XSS attacks. While storing tokens in local storage isn't optimal, it's quite common in SPAs with multi-account functionality. You shouldn’t overthink it. Just ensure you have rate limiting in place for logins and refresh actions, opt for SameSite=Strict for cookies where possible, and ship it. You can always enhance things in future versions! Your hard work shows, and you're doing great!
Try storing the refresh token in an HTTP-only cookie; that way, the client will not need to access the refresh token directly, which enhances security.
Thanks for the input! The challenge is that I'm struggling to figure out how to handle multiple account storage with HTTP-only cookies. I need to manage different tokens for multiple accounts.
Consider hiring a penetration tester to identify any vulnerabilities directly instead of just discussing it here. You want to know where your app might be weak before it goes live.
I appreciate the suggestion! It also depends on my client’s willingness to spend on an audit, but I agree it would definitely be beneficial.
This is why it's often advised against creating your own authentication system. It's tricky and can lead to vulnerabilities if not done correctly.
I actually followed FastAPI's OAuth2 flow as outlined in their docs, so I thought I was following best practices. What’s the danger with that?
Thank you! I tend to overthink things, especially since this is my first major app and I want it to make a good impression. I’ve already added rate limiting on critical endpoints. You’re right; there’s always room for improvement later on.