localStorage – Are Cookies Too Good For You?

I’ve seen several web applications implementing the user session ID (or token) in a custom HTTP header parameters thus avoiding to store the session ID in cookies. Additionally, some public web platforms save the same kind of token to track their user analytics. For instance, recently I notice that this mechanism was utilised by the New Relic REST API platform which is storing the user ID in a HTTP parameter called X-NewRelic-ID.

During testing of an application, I have found both a cross-site scripting and the session ID sent as HTTP header parameter . My goal was to steal the user’s session ID, which was sent to the application as X-Auth-Token in a custom HTTP header parameter.

I was aware that you can technically retrieve the HTTP header of any HTTP message by performing an Ajax request and analysing the response but, this will cost an attacker a lot more JavaScript code; specifically, to create and handle a new Ajax request and subsequently analyse the web server response. In other words, you send an Ajax request and analyse the HTTP response including the header but you cannot retrieve the HTTP header of a request that has been already performed. Which is pretty normal considering this is one of the fundamental law of physics in the browser’s world!

Curious to understand why people persist in the use of this implementation I start searching around for information. I start playing with the web console of my browser while logged into the application – I was looking for the “auth_token” of my account. If I could find the variable that store the authentication token than I could directly retrieve this value without using any Ajax weapon. Simple as that!

I don’t remember how I found it, but honestly it didn’t took long. The authentication token was saved in localStorage and accessible just by performing the following JavaScript command:



What Are the Security Concerns?

Simply, the localStorage.auth_token cannot be restricted to be accessed by JavaScript. If the application is affected by cross-site scripting, an attacker exploiting XSS against an authenticated user can steal the user session – or any type of data stored in localStorage.

In the past 5 years, the security around cookies has improved. All modern browsers accepts the security flags that can be set on cookies by web applications. Security flags are two (categorised as security flags but cookies have more) and are very simple to understand and deploy.

HttpOnly – Is a flag that when applied on cookies disallow JavaScript from accessing the value stored in the cookie parameter

Secure – Disallow the transmission of the cookie to be sent over an unencrypted communication channel as such HTTP.

More information of these security flags and their implementation can be found in the OWASP website:


One more note. Cookies have not only these two flags. The importance of appropriately configure the “domain” and “path” flags on cookies is as crucial as applying the aforementioned conservation flags. If your concern is limiting cookies only to be sent to specific pages or subdomains of the web application, then the answer is: configure “domain” and “path” flags accordingly to your requirements.


So…What is localStorage?

In my understanding is nothing else that what the variable name states, however developers may have different myths on the existence of localStorage.

The following text has been taken from smashmagazine.com (http://www.smashingmagazine.com/2010/10/11/local-storage-and-how-to-use-it/):

“The main problem with HTTP as the main transport layer of the Web is that it is stateless. This means that when you use an application and then close it, its state will be reset the next time you open it. If you close an application on your desktop and re-open it, its most recent state is restored.

This is why, as a developer, you need to store the state of your interface somewhere. Normally, this is done server-side, and you would check the user name to know which state to revert to. But what if you don’t want to force people to sign up?

This is where local storage comes in. You would keep a key on the user’s computer and read it out when the user returns.”

What this guy think cookies have been used in the last 15 years for? It gets better:

“Cookies have a few limitations though:
– They add to the load of every document accessed on the domain.
– They allow up to only 4 KB of data storage.
– Because cookies have been used to spy on people’s surfing behavior, security-conscious people and companies turn them off or request to be asked every time whether a cookie should be set.

I haven’t finished – I want to add a text from w3schools.com (http://www.w3schools.com/html/html5_webstorage.asp):

“With HTML5, web pages can store data locally within the user’s browser.

Earlier, this was done with cookies. However, Web Storage is more secure and faster. The data is not included with every server request, but used ONLY when asked for. It is also possible to store large amounts of data, without affecting the website’s performance.

The data is stored in name/value pairs, and a web page can only access data stored by itself.

Unlike cookies, the storage limit is far larger (at least 5MB) and information is never transferred to the server.”

The above text is correct! But be careful how you interpret it. Bear in mind that they are not referring to session ID. The web storage (localStorage) is used here to contain user’s information but It doesn’t mention the use of session ID or the use of web storage to maintain the state of the user session. Contrary to what was stated in the previous article.



LocalStorage can be a great place for developers to store user information but not a secure place to store the user’s session ID (or token) or other sensitive information. LocalStorage has been preferred to Cookies, but for the only reason of storing large data or information that are not need to be sent at each request to the application.
Finally, localStorage is not the place where you should store the user’s session ID.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s