Html5 Local Storage Vs. Session Storage

HTML5 Local storage vs. Session storage

localStorage and sessionStorage both extend Storage. There is no difference between them except for the intended "non-persistence" of sessionStorage.

That is, the data stored in localStorage persists until explicitly deleted. Changes made are saved and available for all current and future visits to the site.

For sessionStorage, changes are only available per tab. Changes made are saved and available for the current page in that tab until it is closed. Once it is closed, the stored data is deleted.

What is the difference between localStorage, sessionStorage, session and cookies?

This is an extremely broad scope question, and a lot of the pros/cons will be contextual to the situation.

In all cases, these storage mechanisms will be specific to an individual browser on an individual computer/device. Any requirement to store data on an ongoing basis across sessions will need to involve your application server side - most likely using a database, but possibly XML or a text/CSV file.

localStorage, sessionStorage, and cookies are all client storage solutions. Session data is held on the server where it remains under your direct control.

localStorage and sessionStorage

localStorage and sessionStorage are relatively new APIs (meaning, not all legacy browsers will support them) and are near identical (both in APIs and capabilities) with the sole exception of persistence. sessionStorage (as the name suggests) is only available for the duration of the browser session (and is deleted when the tab or window is closed) - it does, however, survive page reloads (source DOM Storage guide - Mozilla Developer Network).

Clearly, if the data you are storing needs to be available on an ongoing basis then localStorage is preferable to sessionStorage - although you should note both can be cleared by the user so you should not rely on the continuing existence of data in either case.

localStorage and sessionStorage are perfect for persisting non-sensitive data needed within client scripts between pages (for example: preferences, scores in games). The data stored in localStorage and sessionStorage can easily be read or changed from within the client/browser so should not be relied upon for storage of sensitive or security-related data within applications.

Cookies

This is also true for cookies, these can be trivially tampered with by the user, and data can also be read from them in plain text - so if you are wanting to store sensitive data then the session is really your only option. If you are not using SSL, cookie information can also be intercepted in transit, especially on an open wifi.

On the positive side cookies can have a degree of protection applied from security risks like Cross-Site Scripting (XSS)/Script injection by setting an HTTP only flag which means modern (supporting) browsers will prevent access to the cookies and values from JavaScript (this will also prevent your own, legitimate, JavaScript from accessing them). This is especially important with authentication cookies, which are used to store a token containing details of the user who is logged on - if you have a copy of that cookie then for all intents and purposes you become that user as far as the web application is concerned, and have the same access to data and functionality the user has.

As cookies are used for authentication purposes and persistence of user data, all cookies valid for a page are sent from the browser to the server for every request to the same domain - this includes the original page request, any subsequent Ajax requests, all images, stylesheets, scripts, and fonts. For this reason, cookies should not be used to store large amounts of information. The browser may also impose limits on the size of information that can be stored in cookies. Typically cookies are used to store identifying tokens for authentication, session, and advertising tracking. The tokens are typically not human readable information in and of themselves, but encrypted identifiers linked to your application or database.

localStorage vs. sessionStorage vs. Cookies

In terms of capabilities, cookies, sessionStorage, and localStorage only allow you to store strings - it is possible to implicitly convert primitive values when setting (these will need to be converted back to use them as their type after reading) but not Objects or Arrays (it is possible to JSON serialise them to store them using the APIs). Session storage will generally allow you to store any primitives or objects supported by your Server Side language/framework.

Client-side vs. Server-side

As HTTP is a stateless protocol - web applications have no way of identifying a user from previous visits on returning to the web site - session data usually relies on a cookie token to identify the user for repeat visits (although rarely URL parameters may be used for the same purpose). Data will usually have a sliding expiry time (renewed each time the user visits), and depending on your server/framework data will either be stored in-process (meaning data will be lost if the web server crashes or is restarted) or externally in a state server or database. This is also necessary when using a web-farm (more than one server for a given website).

As session data is completely controlled by your application (server side) it is the best place for anything sensitive or secure in nature.

The obvious disadvantage of server-side data is scalability - server resources are required for each user for the duration of the session, and that any data needed client side must be sent with each request. As the server has no way of knowing if a user navigates to another site or closes their browser, session data must expire after a given time to avoid all server resources being taken up by abandoned sessions. When using session data you should, therefore, be aware of the possibility that data will have expired and been lost, especially on pages with long forms. It will also be lost if the user deletes their cookies or switches browsers/devices.

Some web frameworks/developers use hidden HTML inputs to persist data from one page of a form to another to avoid session expiration.

localStorage, sessionStorage, and cookies are all subject to "same-origin" rules which means browsers should prevent access to the data except the domain that set the information to start with.

For further reading on client storage technologies see Dive Into Html 5.

Local Storage Vs Session Storage Advice needed

to begin with, I want to say I really liked your CSS :).

You don't have to use a database or redux for making a cart system, but as you can guess they have good opportunities.

---

DATABASE ADVANTAGES:

1. You can show the user's cart on all his devices.
2. User's cart will be always here as long as he did not delete it.
3. You can reach the data on all components. (hard)
4. It's very good practice for learning.

DATABASE DISADVANTAGES:

1. You need an API so, it's hard to set up.
2. Your code will be more complicated than other choices.

---

REDUX ADVANTAGES

1. It's kinda easy to set up. You don't need a new project.
2. You can reach the data on all components. (medium)

REDUX DISADVANTAGES

1. Actually I really don't know any disadvantages of redux :) (pls tell me if you know)

---

LOCALSTORAGE ADVANTAGES

1. Very easy
2. You can reach the data on all components. (easy)

LOCALSTORAGE DISADVANTAGES

1. You can't show a user's cart on another device

---

I didn't separate session storage because it's the same as local storage. The only difference is session storage is per-tab.

In my opinion, you should use a database. I know it's a basic app but you can learn a lot of things by doing it this way.

And these are my recommendations:

1. cookies vs local vs session storage

2. ECommerce site with backend

localStorage vs sessionStorage vs cookies

localStorage and sessionStorage are both so-called WebStorages and features of HTML5.

localStorage stores information as long as the user does not delete them.

sessionStorage stores information as long as the session goes. Usually until the user closes the tab/browser.

cookies are simply cookies, which are supported by older browsers and usually are a fallback for frameworks that use the above mentioned WebStorages.

In contrast cookies can store way less information then WebStorages and the information in WebStorages is never transferred to the server.

Keep in mind that the EU has a regulation that requires websites to inform their users about the usage of cookies. I dont know whether this also applies to WebStorages

Clear local storage on session clear

Use sessionStorage. It has the same methods as localStorage, but it clears when the session is cleared.

How to combine advantages of localStorage and sessionStorage

We use cookies.

Storages have their uses.
But cookies meet all your requirements.

• Cookies are shared across all same origin tab. You can even specify their paths, but they are shared by default.

• Cookies are automatically deleted by browser when it is closed, you need to do nothing; this is again the default behaviour.

• Cookies can be easily made as secure or more secure than storage.

Sometime the best solution is the simplest solution.
No need to reinvent the wheel.

Cookie Security

Session cookie is stored on disk like sessionStorage (in case the browser crash and need to recover).
So they are about equally secure in term of local disk read/write.

Both cookie and storage processing script may be acquired or even stolen during http transfer,
so you must use HTTPS for both cases.
(This is the least you should do.)

Cookie can be configured to be HTTP only,
preventing JavaScript from accessing it,
thus making immune from XSS script and greasemonkey hijacking.

In case when an auth token is stolen, we also associate each token with the machine's user agent and ip.
This prevent the token from being used by someone from external network.
If you want, you can add more content negotiation headers to the mix - not all robots copy all headers.

For another level of security, you can add client side fingerprinting.
These fingerprints must be captured on client side and transferred over network, so they are not bulletproof,
but they will force internal attackers (attackers on same network with the user) to jump through another hoop.

At this point, they will usually switch to easier attacks outside your control.

---

Related Topics