Web Storages and Cookies


While I was implementing the login feature, I was wondering what the best practice would be regarding where to store the JWT token.

Local Storage & Session Storage

There are two types of storage in web: localStorage and sessionStorage. These two allow saving key-value pairs within the browser (up to 5MB). The difference between these two is the lifecycle of persisted data.

The data saved in sessionStorage will be cleared when a user refreshes the page or reopens the browser. Also, if there are multiple tabs of the same page, each tab will have an isolated storage.

On the other hand, all data saved in localStorage stays persisted even if a tab or browser is closed. The data is also shared across the tabs. This all applies as long as a same browser on a same computer is used. If a computer has different browsers installed, each browser will have an isolated localStorage.

But then, what are Cookies?

A cookie is a small piece of data (max 4K after encoding) that a server sends to a user’s web browser. If server puts Set-Cookie header in HTTP response, the browser will store the values as cookies. Also, stored cookies are forwarded in Cookie header in future HTTP requests to the server.

Cookie Attributes

  • path: Only sites that are on the same path or sub-path can access a cookie with path attribute set.
  • domain: domain attribute specifies the which host domain can access a cookie. If this attribute is not set, only the domain who set the cookies can access them. Also, cookies are available in subdomains.
  • expires & max-age: Session cookies, which are deleted when the current session ends, can be created without defining expires or max-age attribute. Permanent cookies are deleted after the date specified by expires attribute or after some time specified by max-age.
  • secure: A cookie with secure attribute is sent to the server over HTTPS protocol only. Also, insecure sites that starts with http:// cannot set a cookie with secure attribute.
  • httpOnly: A cookie with httpOnly attribute cannot be accessed via document.cookie API in JavaScript because it is only used to send to the server. This can provide protection against Cross-site scripting (XSS).
  • samesite: This attribute is to protect against cross-site request forgery (CSRF) attacks. With none, all cookies can be sent from the same site and cross site with different domains. With this attribute set as strict, cookies cannot be sent from cross site. With lax, it works like strict but has some exceptions. It allows for safe HTTP methods such as GET and for top-level navigation such as a href and link href.


WebStorage can be great storing client side data while it can hold more data compared to cookies. Cookies can be useful for storing server side data because it automatically sends requests to the server. On top of that we looked into how different attributes of a cookie can help with security. These should be considered based on the application’s needs and usages.






Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Code First with Spring Boot, Hibernate and Liquibase

How I hate writing so many services using dot net core and how I reduced the number of services

Beyond the Buzz: API Management Theory vs. Implementation

Getting Started With Kubernetes Operators (Golang Based) — Part 3

AV Ecosystem Review: Adding NodeJS Tests

The MEAN Stack

Authenticating REST services with OAuth2

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store



More from Medium

Recursion and stack

Data Structures & Algorithms in JavaScript(Hash Table)

Leetcode — Implement Queue using Stacks — Easy

HackerRank —Write a function