What is local storage?
For example, when you set a preference for website A to use a dark theme, this is stored as a key-value pair on your browser, so the next time you visit website A, it remembers your preference and will use a dark theme.
This is because local storage is persistent, which means that it will never expire. As long as the browser cache is not manually cleared by the user, these key-value pairs persist even when the browser is shut down and/or restarted.
The catch is that it is only retrievable by the same website.
On the other hand, the Hypertext Transfer Protocol, or more commonly known as HTTP, is a stateless protocol, i.e. the server does not keep track of the state of the client.
Let’s look at the website (https://set-localstorage.herokuapp.com/) to illustrate the usage of local storage via HTTP.
Imagine a scenario where a student logs in to their academic portal via HTTP and has to update their particulars such as their name and NRIC.
Although the data is submitted to the server, the developer designed the website to display the information on the main page.
As HTTP is a stateless protocol, this means that every time the student goes to the main page, the website has to resend the request to retrieve the particulars of the user. To simplify this process and make it more convenient for end-users, the developer can make it such that the information is retrieved from the browser’s local storage rather than retrieving it again from the server.
Clearing local storage
As seen in the screenshot below, the “name” and “NRIC” of the user were stored in the user’s browser.
Although it is possible to implement functions to clear the local storage when the user logs out or when the validity of the session timeouts, there are cases where websites do not clear the information at all.
Local storage is persistent
Local storage remains persistent even after closing and reopening the browser. The information stored on the local storage will remain available on the user’s browser.
This usually does not present a security concern if the student was using his own PC to access and fill in the form. However, if he was accessing the site and filling up the form from a public terminal, such as one in the library, the next user using the same browser would be able to access and see his name and NRIC in the browser’s local storage.
Besides being openly accessible to anyone who next uses the same browser, there are other ways where local storage can be misused. Below are two examples.
Cross-site scripting (XSS)
In an actual hacking situation, the user will not even notice the sensitive information was already captured by the hacker. The information would be sent to the hacker’s server instead via XSS.
How to prevent the misuse of local storage
Given the potential vectors where malicious actors can access information on your browser's local storage, it is easy to see why sensitive information such as Personally Identifiable Information (PII), authentication tokens, user locations and API keys, etc., should never be stored in the local storage.
Local storage should only be used to store non-sensitive data like users’ preferences such as themes, language, etc.
The following are several ways where an attacker could retrieve the sensitive information stored in the local storage:
- Physical access to the browser
- Cross Domain Script Included
Therefore, to prevent local storage attacks, websites should follow best practices and only store sensitive data on the server-side.