DEV Community

DaNeil C
DaNeil C

Posted on • Updated on

localStorage VS sessionStorage

While working on my final project for Flatiron School I discovered a security issue with the localStorage that I was being told to use.

So, to refresh, "Similar to "sessionStorage", localStorage is a read-only property that allows access to a "Storage object for the Document's origin; the stored data is saved across browser sessions." (5) Note: that data stored in localStorage has no expiration time so it must be set if desired.

In my case I needed to use the setItem method on the localStorage object for the JWT object when a user logs in and save it in the browser and then clear the localStorage of the JWT object once the user logged out. This will allow all user associated state to be cleared and reset also so that no one else could go to the site and use their login credentials." (1)

Plot Twist Time!!

The issue comes up with how localStorage stores information. Like a lot of websites, when you close a tab or window, the browser retains some session information so that you don't need to login each and every time you navigate to a site. With localStorage there is no timeout setting for this information, thus, the user information never leaves the browser. This might seem like a good idea so users don't need to remember more login information, but if you are developing a site it is good to force sign out at some interval to ensure that users data is more secure.

How does localStorage cause an issue though?

Well, "if an attacker can run JavaScript on your website, they can retrieve all the data you've stored in local storage and send it off to their own domain. This means anything sensitive you've got in local storage (like a user's session data) can be compromised." (2)

This is where sessionStorage becomes the better choice.

Though sessionStorage properties also allow a key/value pair in a web browser just like localStorage, sessionStorage is a better choice over localStorage because session data is cleared when the browser tab is closed. This is important because... if someone can get a copy of your JWT then they can make requests on your behalf. This is bad.

When to use it?

Any time you have information you wouldn't share on a social media site such as... JWT, Usernames, Passwords, Credit Card information API keys, AWS credentials, or personally identifying information. Really, the list could go on but as a developer, these are the main things to consider using a sessionStorage for.

Syntax difference? Nope.

The syntax for creating an object in storage, deleting an object, and accessing an object are basically the same between localStorage and sessionStorage.

Alt Text
Alt Text

Which to use???

This depends on the information you are storing. If you are building a static single-page app like my Flatiron School project, using localStorage means that the site can run independently of any web server, which is cool, but my project is focused on security and if you are building anything that is going to handle any sensitive information, then use a sessionStorage. And, if you do used localStorage for a simple single-page app that is just giving information and doesn't store anything, you could use localStorage, or set the localStorage to timeout after "x" amount of time.
Alt Text

For my project I decided to use sessionStorage because it is the more secure way to go and it didn't take anything extra except changing all of my "localStorage" to "sessionStorage". Now when I close the tab I am working in, it logs me out automatically. The browsers can be set up to store passwords so I would rather use my in browser password manager to remember these login credentials than let the localStorage object retain the information it doesn't need.


Please Note that I am a student and still learning. If something that I have stated is incorrect please let me know. I would love to learn more about what I may not understand fully.

Discussion (1)

hulf profile image

To also add to your discussion, can also be attacked via XSS javascript, so it is still not a good idea to store anything secure in it. The only currently secure place to store creds is in a cookie and then only if the HTTPOnly and Secure flags are set. This then means that the data cannot be seen via javascript, only the web server. So then any break in via XSS can not retrieve the data and then have someone else use that.

Now as an aside, in theory you could encrypt the data stored and encode in the source ip address of the browser, so if someone does try to reuse it, you can ignore the data as the encoded ip wouldn't match the ip that they were coming from. Again this would have to be done at the web server level were it can see the internet ip address, not the client browser ip, as they will more than likely be nated, so not unique.