auth security
Hey all - I am a newbie to wasp and to anything related to auth security. I’ve seen it mentioned that using localstorage is bad form as it’s vulnerable to xss attacks. Anything to worry about here?
4 Replies
Hi @neilmorr. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Yes, you're correct. Storing sensitive data like authentication tokens in local storage can expose your application to certain types of attacks, such as Cross-Site Scripting (XSS). This is because local storage is accessible through JavaScript, and thus can be accessed by malicious scripts.
In Wasp, there is an ongoing discussion about whether to use sessions instead of JWT for authentication, and whether to use cookies instead of local storage. The main concern is about the security implications of each approach. For example, while using cookies can help mitigate the risk of XSS attacks (especially if the HttpOnly attribute is used), it introduces other potential issues, such as Cross-Site Request Forgery (CSRF) attacks.
In a Github issue (https://github.com/wasp-lang/wasp/issues/573), a contributor mentioned that websites using local storage don't have a choice but to fall into the category of being vulnerable to XSS attacks, as session IDs are always accessible through JavaScript. They suggested leaning towards using the HttpOnly attribute, which is often recommended as a security must-have.
However, it's important to note that no solution is perfect and each comes with its own set of trade-offs. The key is to understand these trade-offs and make an informed decision based on the specific needs and context of your application.
For more information on how Wasp handles authentication, you can refer to the Wasp documentation (https://wasp-lang.dev/docs/tutorial/auth). It provides a step-by-step guide on how to add authentication to your Wasp app, including creating a User entity, enabling username and password authentication, and adding login and signup pages.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @neilmorr, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
Great question @neilmorr - the bot actually did an OK job here. The GitHub issue it linked (https://github.com/wasp-lang/wasp/issues/573) is exactly where I would point you! 😄
I suggest giving that one a thorough read - Not because you need to know all that stuff to use Wasp, but because it's an interesting discussion that will teach you a lot about session and token management in web apps. Make sure to follow the two links in the issue's description, they're two of the best articles I've found on this topic.
If the discussion in the issue is too long and too dry for your taste, here's a link to a talk I recently gave at a web meetup: https://sodic.github.io/cookies-vs-jwts.pdf.
It's short, sweet, and deals with two dilemmas:
- Sessions or JWTs
- Local storage or Cookies
Slides 41 and 57 have feature nice tables explaining all the tradeoffs between different approaches.
The shortest possible version of all of this is:
Wasp decided to use
localStorage because we wanted to support deploying the client on a different domain than the server, and yes, this means that our session IDs are open to XSS attacks which isn't ideal, but isn't as big of a deal as you may think (more details in the resources).Yup, and even popular solutions like Supabase are using localStorage, if that helps regarding making a decision.
Awesome. Thank you @sodic and @martinsos!