One of the most popular myths in the web dev community is around cookies & local storage. It's also a commonly asked interview question. Let's uncover the concept behind these two storage mechanisms!
Introduction to Cookies
Cookies are small files that are located on a userβs computer. They are designed to hold a generous amount of data specific to a client and website, and they can be accessed either by the web server or the client computer.
- The reason behind this is to allow the server to deliver a page tailored to a particular user, or the page itself can contain some script that knows of the data in the cookie, and therefore it can carry information from one visit to the website to the next.
- Each cookie is effectively a small lookup table containing pairs of the key, data values.
- Cookies are primarily for reading server-side.
- Introduced before HTML5.
- Has an expiration date.
- Cleared by JS or by Clear Browsing Data of browser or after expiration date.
- Will be sent to the server per each request.
- The capacity is 4KB.
- Only strings can be stored in cookies.
- There are two types of cookies: persistent and session.
Disadvantages:
- Each domain stores all its cookies in a single string, which can make parsing data difficult.
- Data is unencrypted, which becomes an issue because though small in size, cookies are sent with every HTTP request.
- SQL injection can be performed from a cookie.
- If we have unnecessary cookies, they will be sent with all the requests and responses and hence slow down the application.
Introduction to LocalStorage
localStorage is an implementation of the Storage Interface. It stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser Cache / Locally Stored Data β unlike cookie expiry.
- Local Storage is as big as 5MB per domain.
- Local storage can only be read by the client-side.
- Introduced with HTML5.
- Does not has an expiration date.
- Cleared by JS or by Clear Browsing Data of the browser.
- You can select when the data must be sent to the server.
- Data is stored indefinitely and must be a string.
- Only have one type.
- Support by most modern browsers
- Same-origin rules apply to local storage data
localStorage will not be available if you switch from 'HTTP' to 'HTTPS' secured protocol, where the cookie will still be accessible.
Disadvantages:
- Data once stored is persistent. It is the duty of the application to clean data after use.
- Data stored in localStorage is not secured. Never store sensitive information to localStorage.
Find more information about cookies and local storage on the links below:
If you found this article insightful and helpful, then do let me know your views in the comments. In case you want to connect with me, follow the links below:
LinkedIn | GitHub | Twitter | StackOverflow
Top comments (13)
I agree with you about we did not store a sensitive data in localStorage. Actually, It's a place for access_token(public data) that is enough.
What about store user info like email, phone number and name
And his access_token
All of them encrypted
In local storage
Hey Asim, ideally, you can't secure local storage and it is not recommended to store any sensitive data in local storage. You can try and encrypting it, but there is a catch. Encrypting it on the client is possible, but would mean the user has to provide a password and you have to depend on not-so-well-tested javascript implementations of cryptography.
Encrypting on the server side is of course possible, but then the client code cannot read or update it, and so you have reduced localStorage to a glorified cookie.
If it needs to be secure, its best to not send it to the client. What is not in your control can never be secure.
How to encrypt all above of them. I have no idea about it.
Although, it's not preferred to store data in localStorage but if you want to encrypt it, you can try the below links:
Thank you for your information. I was read both of them on gitHub. I think the secure-ls libraries sound good. but I don't have idea to used it for more secured my localStorage because I need to set a key in client application(like js) and it's can read by browser network tab(Edge, Chrome). Thank you for your advice.
Worth noting that server cookies sent over HTTPS with the
Secureflag are indeed encrypted.Great content, Verma.π₯°
From this, β SQL injection can be performed from a cookieβ.
Could you provide a verbose possibility of this? Like whatβs the possible code scenario through which this can happen.
Thank you.
Is the local Storage really as big as 5Mb per domain in general? I use an application storing a bit more thereβ¦
Hey, Johann. localStorage capacity varies by browser, with 2.5MB, 5MB, and unlimited being the most common values. Google Chrome, Mozilla Firefox, and Opera provide 10MB per origin. You can also customize the storage size.
Hope this helps. If you have any other doubts, let me know.
Thanks for the answer!
What about store user info like email, phone number and name
And his access_token
All of them encrypted
In local storage
Hey Asim, ideally, you can't secure local storage and it is not recommended to store any sensitive data in local storage. You can try and encrypting it, but there is a catch. Encrypting it on the client is possible, but would mean the user has to provide a password and you have to depend on not-so-well-tested javascript implementations of cryptography.
Encrypting on the server side is of course possible, but then the client code cannot read or update it, and so you have reduced localStorage to a glorified cookie.
If it needs to be secure, its best to not send it to the client. What is not in your control can never be secure.