What is Client Side Storage?

cookie image from Pinterest

What’s the first thing on your mind when you hear ‘Client-side storage’? Browser Cookies or Chocolate cookies?

In general, browsers have different ways to store and retrieve data on your user’s computer. Storage is unique to each domain. Developers can choose to store things such as:

• Color Scheme
• Font Size or Font Family
• Shopping Cart
• Session Data
• Game Progress
• More complex data such as Music, Videos and pictures

When you visit your browser dev tool in Chrome using F12, navigate to the application and under Storage you can see things such as Local Storage, Session Storage, IndexedDB, Web SQL, Cookies, Private State Tokens, Interest Groups, Shared Storage and Cache Storage. For today we’ll briefly look at Cookies, Web storage and IndexedDB which are the most popular.

1. Web Storage: Web storage is essentially used to store key/value pairs using two similar APIs:
   - Local Storage: stores persistent data.
   - Session Storage: stores session-only data.
   Web Storage (Local Storage and Session Storage) has a maximum of 5 MB for each API. Session Storage only keeps data while the tab is active; and closing the browser clears Session Storage, while Local Storage needs to be deleted since it's persistent. Web storage uses the setItem, getItem and removeItem methods to handle storage, while setItem accepts both key and value arguments - getItem and removeItem takes only the key, and these methods clearly does the same thing its implies. One of the drawbacks of using web storage is that it only accepts strings.
2. Cookies: Http Cookies are one of the oldest and most popular form of storage on the client side. Cookies are familiar to both frontend and backend developers, Security Professionals, testers, etc. Cookies are small pieces of data with maximum of 80kb with at most 20 cookies and a maximum of 4kb for each cookie. Cookies are sent by server and browser to each other. Personally I feel cookies are the most secure way to store data on client reason being that client side access can be disabled and https (secure http) enforced. Mind you sensitive or personal identifying data such as email, gender, etc. should not be stored on the client as certain harvesting tools can access these data and attackers can end up doing horibble things with it; you might be thinking JWT?
   In your console, when you run ‘document.cookie.split(‘;’)’ you only get cookies without the httponly flag. The secure flag tells the browser to send cookies only when https is being used, this adds an extra level of security against MITM attacks. Another thing to note is that it’s only posible to set cookies from server when you’re on:
   - Same domain: localhost.com > localhost.com
   - Same domain with different ports: localhost:5000 > localhost:3000
   - Same domain with different subdomain: api.localhost > client.localhost
   In cases where you’re on different subdomain and different port, setting/accessing cookies is not possible.
   samesite: sets domain cookie access (lax — current domain, none — no restrictions, strict — only for same-site requests).
   There are more options when setting cookies such as domain, path, max-age, and expires
3. IndexedDB: Allows usage of up to 50% of client disk space. To access this NoSQL like database, we can use
   > const indexDB = window.open(‘database_name’, ‘database_version’).
   A new database is created if the specified version doesn’t exist. Bear in mind that database operations are slow and might look fast in development, but you need consider performance on low-end devices. This storage mechanism uses asynchronous methods, so we can add event listeners with JavaScript such as ‘error’, ‘success’, etc. This is the largest of all client side storage.

✌

More content at PlainEnglish.io.

Sign up for our free weekly newsletter. Follow us on Twitter, LinkedIn, YouTube, and Discord.