Is it safe to store a JWT in localStorage with ReactJS

Question

I m currently building a single page application using ReactJS  I read that one of the reasons for not using localStorage is because of XSS vulnerabilities  Since React escapes all user input  would it now be safe to use localStorage

User · Answer

I know this is an old question but according what @mikejones1477 said, modern front end libraries and frameworks escape the text giving you protection against XSS. The reason why cookies are not a secure method using credentials is that cookies doesn't prevent CSRF when localStorage does (also remember that cookies are accessible by javascript too, so XSS isn't the big problem here), this answer resume why.

The reason storing an authentication token in local storage and manually adding it to each request protects against CSRF is that key word: manual. Since the browser is not automatically sending that auth token, if I visit evil.com and it manages to send a POST http://example.com/delete-my-account, it will not be able to send my authn token, so the request is ignored.

Of course httpOnly is the holy grail but you can't access from reactjs or any js framework beside you still have CSRF vulnerability. My recommendation would be localstorage or if you want to use cookies make sure implemeting some solution to your CSRF problem like django does.

Regarding with the CDN's make sure you're not using some weird CDN, for example CDN like google or bootstrap provide, are maintained by the community and doesn't contain malicious code, if you are not sure, you're free to review.

User · Answer

It is safe to store your token in localStorage as long as you encrypt it  Below is a compressed code snippet showing one of many ways you can do it       import SimpleCrypto from  simple-crypto-js        const saveToken    token         gt              const encryptInit   new SimpleCrypto  PRIVATE KEY STORED IN ENV FILE              const encryptedToken   encryptInit encrypt token              localStorage setItem  token   encryptedToken            Then  before using your token decrypt it using PRIVATE KEY STORED IN ENV FILE

User · Answer

A way to look at this is to consider the level of risk or harm    Are you building an app with no users  POC MVP  Are you a startup who needs to get to market and test your app quickly  If yes  I would probably just implement the simplest solution and maintain focus on finding product-market-fit  Use localStorage as its often easier to implement    Are you building a v2 of an app with many daily active users or an app that people businesses are heavily dependent on  Would getting hacked mean little or no room for recovery  If so  I would take a long hard look at your dependencies and consider storing token information in an http-only cookie    Using both localStorage and cookie session storage have their own pros and cons    As stated by first answer  If your application has an XSS vulnerability  neither will protect your user  Since most modern applications have a dozen or more different dependencies  it becomes increasingly difficult to guarantee that one of your application s dependencies is not XSS vulnerable    If your application does have an XSS vulnerability and a hacker has been able to exploit it  the hacker will be able to perform actions on behalf of your user  The hacker can perform GET POST requests by retrieving token from localStorage or can perform POST requests if token is stored in a http-only cookie    The only down-side of the storing your token in local storage is the hacker will be able to read your token

User · Answer

Isn t neither localStorage or httpOnly cookie acceptable  In regards to a compromised 3rd party library  the only solution I know of that will reduce   prevent sensitive information from being stolen would be enforced Subresource Integrity      Subresource Integrity  SRI  is a security feature that enables   browsers to verify that resources they fetch  for example  from a CDN    are delivered without unexpected manipulation  It works by allowing   you to provide a cryptographic hash that a fetched resource must   match    As long as the compromised 3rd party library is active on your website  a keylogger can start collecting info like username  password  and whatever else you input into the site   An httpOnly cookie will prevent access from another computer but will do nothing to prevent the hacker from manipulating the user s computer

User · Answer

Localstorage is designed to be accessible by javascript  so it doesn t provide any XSS protection  As mentioned in other answers  there is a bunch of possible ways to do an XSS attack  from which localstorage is not protected by default   However  cookies have security flags which protect from XSS and CSRF attacks  HttpOnly flag prevents client side javascript from accessing the cookie  Secure flag only allows the browser to transfer the cookie through ssl  and SameSite flag ensures that the cookie is sent only to the origin  Although I just checked and SameSite is currently supported only in Opera and Chrome  so to protect from CSRF it s better to use other strategies  For example  sending an encrypted token in another cookie with some public user data    So cookies are a more secure choice for storing authentication data

User · Answer

It is not safe if you use CDN s       Malicious JavaScript can be embedded on the page  and Web Storage is compromised  These types of XSS attacks can get everyone   s Web Storage that visits your site  without their knowledge  This is probably why a bunch of organizations advise not to store anything of value or trust any information in web storage  This includes session identifiers and tokens       via stormpath   Any script you require from the outside could potentially be compromised and could grab any JWTS from your client s storage and send personal data back to the attacker s server

User · Answer

In most of the modern single page applications  we indeed have to store the token somewhere on the client side  most common use case - to keep the user logged in after a page refresh   There are a total of 2 options available  Web Storage  session storage  local storage  and a client side cookie  Both options are widely used  but this doesn t mean they are very secure  Tom Abbott summarizes well the JWT sessionStorage and localStorage security   Web Storage  localStorage sessionStorage  is accessible through JavaScript on the same domain  This means that any JavaScript running on your site will have access to web storage  and because of this can be vulnerable to cross-site scripting  XSS  attacks  XSS  in a nutshell  is a type of vulnerability where an attacker can inject JavaScript that will run on your page  Basic XSS attacks attempt to inject JavaScript through form inputs  where the attacker puts  lt script gt alert  You are Hacked    lt  script gt  into a form to see if it is run by the browser and can be viewed by other users   To prevent XSS  the common response is to escape and encode all untrusted data  React  mostly  does that for you  Here s a great discussion about how much XSS vulnerability protection is React responsible for  But that doesn t cover all possible vulnerabilities  Another potential threat is the usage of JavaScript hosted on CDNs or outside infrastructure  Here s Tom again   Modern web apps include 3rd party JavaScript libraries for A B testing  funnel market analysis  and ads  We use package managers like Bower to import other peoples    code into our apps  What if only one of the scripts you use is compromised  Malicious JavaScript can be embedded on the page  and Web Storage is compromised  These types of XSS attacks can get everyone   s Web Storage that visits your site  without their knowledge  This is probably why a bunch of organizations advise not to store anything of value or trust any information in web storage  This includes session identifiers and tokens   Therefore  my conclusion is that as a storage mechanism  Web Storage does not enforce any secure standards during transfer  Whoever reads Web Storage and uses it must do their due diligence to ensure they always send the JWT over HTTPS and never HTTP

User · Answer

Basically it s OK to store your JWT in your localStorage    And I think this is a good way   If we are talking about XSS  XSS using CDN  it s also a potential risk of getting your client s login pass as well  Storing data in local storage will prevent CSRF attacks at least    You need to be aware of both and choose what you want  Both attacks it s not all you are need to be aware of  just remember  YOUR ENTIRE APP IS ONLY AS SECURE AS THE LEAST SECURE POINT OF YOUR APP       Once again storing is OK  be vulnerable to XSS  CSRF     isn t

[reactjs] Is it safe to store a JWT in localStorage with ReactJS?

Examples related to reactjs

Examples related to local-storage

Examples related to jwt