Q: Where are tokens generally stored? What is the difference between placing Token in cookie and localStorage or sessionStorage?

Think about the outline

  • What is a Token?
  • Token Storage Location
  • Token in cookie, localStorage, sessionStorage.
  • conclusion

What is Token?

Token is actually a credential to access resource pairs.

After a user successfully logs in using the user name and password, the server digitally signs the login credentials and encrypts them to generate a character string as a token.

2. Token storage location

Token is actually a credential to access resource pairs.

After a user successfully logs in using the user name and password, the server digitally signs the login credentials and encrypts them to generate a character string as a token.

It is returned to the client after successful login. The client can store it in the following ways:

  1. It is stored in localStorage and passed to the background as a field each time the interface is called
  2. Store it in a cookie and let it send automatically, but the downside is that it doesn’t cross domains
  3. After getting it, it is stored in localStorage and placed in the Authorization field of HTTP request header each time the interface is called.

The token is stored in localStorage, cookie, or sessionStorage on the client.

3. What is the difference between cookie, localStorage and sessionStorage?

3.1 Storing Tokens in localStorage or sessionStorage

Web storage (localStorage/sessionStorage) can use the same domain Javascript access. This means that any JavaScript running on your site has access to the Web store and is therefore vulnerable to XSS attacks. In particular, the project uses many third-party JavaScript libraries.

To prevent XSS, the common procedure is to avoid and encode all untrusted data. However, this is not 100% protection against XSS. For example, we use JavaScript libraries hosted in the CDN or some other public JavaScript library, and package managers like NPM to import other people’s code into our application.

What if one of the scripts you use is stolen? Malicious JavaScript can be embedded in pages and the Web storage can be stolen. These types of XSS attacks can get everyone’s Web store to access your site.

This is why many organizations advise against storing any valuable or trusting information in a Web store. This includes session identifiers and tokens. As a storage mechanism, Web storage does not enforce any security standards during transport.

XSS attack: Cross-Site Scripting (XSS for short) is a code injection attack. The attacker injects malicious scripts into the target website and makes it run on the user’s browser. By using these malicious scripts, attackers can obtain sensitive user information such as cookies and sessionIDS, thus compromising data security.

3.2 Storing Tokens and Cookies

Advantages:

  • You can specify HttpOnly to prevent it from being read by JavaScript, or secure to ensure that tokens are transmitted only over HTTPS.

Disadvantages:

  • Does not comply with Restful best practices. Restful Best Practices
  • Vulnerable to CSRF attacks (check Refer and Origin on the server side)

CSRF: Cross-site request forgery, simply put, is a technique by which an attacker tricks a user’s browser into visiting a previously authenticated web site and performing operations (such as emailing, sending messages, or even property operations such as transferring money or buying goods). Because the browser has been authenticated, the site being visited will act as if it were a genuine user action. This exploits a flaw in user authentication on the Web: simple authentication guarantees that a request is sent from a user’s browser, but it does not guarantee that the request itself is voluntarily sent by the user. CSRF doesn’t get any information about the user, it just tricks the user’s browser into acting on their behalf.

conclusion

There are two opinions about whether token exists in cookie or localStorage.

  • Cookie-friendly developers would strongly advise against storing sensitive information (such as JWT) in localStorage because it has no resistance to XSS.
  • The school in favor of localStorage argues that, despite its various advantages, the benefits of proper XSS protection far outweigh the risks.

Putting it in cookies looks like a complete solution, looks like “solving” one problem (because there are still XSS issues), but introduces another problem (CSRF)

LocalStorage features more flexibility, more space, and natural immunity to CRSF. Cookies have limited space, and half of the JWT takes up a lot of bytes, and sometimes you need to store more than one JWT.

What is JWT?

Make sure your code as well as third-party library code has adequate XSS checking on top of which store the token in localStorage.

With XSS, even if your httpOnly cookie cannot be accessed, a hacker can still induce or do anything without the user’s knowledge. Remember! The hacker’s code is as trusted by users as your code! As long as XSS exists, storing information in cookies or localStorage is just as vulnerable, the only difference being the difficulty of obtaining it. XSS vulnerabilities are hard to detect because a website is not just built on your own code, but also on third-party code that may have XSS.

Knowledge guide:

What is the JWT

Restful Best Practices

XSS