Web Storage is a technology for client-side storage that enables web applications to save data on the user’s computer. As a considerable amount of information regarding the use of sessionStorage and localStorage already exists so we will not cover it here but only forcus on security. Web Storage was developed as a substitute for cookies, but has certain limitations that we’ll delve into that make it a non-starter for most use cases.

TL;DR

Do not store any personal data or authentication data in Web Storage. To maintaindata security, it is imperative not to send it to the client for storage. Use cookies to store authentication data at the client side. Do not store data for longer than you need.

In cases where Web Storage must be utilised, it is essential to be well-informed about the security and functional implications of this storage mechanism. Keep in mind that any data originating from the client-side is considered untrustworthy. You may encrypt data before saving it on the client-side, but this approach may entail costs that outweigh the benefits of storing it the server side.

How the data is stored

The storage mechanism for data can vary across browsers, and the HTML5 standard does not specify any particular implementation guidelines. This means that there is no requirement to ensure that sessionStorage is stored only in memory. Firefox, for instance, utilizes SQLite as a backend to store data on disk, regardless of whether localStorage, sessionStorage, IndexedDB, or WebSQL is chosen. On the other hand, Chrome uses a single browser cache file per Fully Qualified Domain Name (FQDN). The implementation of sessionStorage in other browsers may differ. It is important to note that unlike session cookies, sessionStorage does not offer any guarantees regarding non-volatility, and data is not encrypted when it is at rest.

Persistence

The behavior of sessionStorage is such that it only persists as long as the window or tab from which it originates remains open. In contrast to session cookies, which expire when the browser is closed (not just the tab), this can render sessionStorage unsuitable for storing session IDs/tokens in situations where users frequently use multiple tabs within a single-page application.

On the other hand, localStorage can be saved indefinitely, or until the user manually deletes it. However, most users are not familiar with how to do this. Additionally, the persistence of localStorage is not guaranteed. For example, Apple has relocated the location of localStorage files to a cache folder, which may be subject to periodic cleanup on iOS devices.

Private browsing

When it comes to Web Storage, Safari has a strict policy of not allowing it in Private Browsing mode. Any attempts to set an item using localStorage.setItem during or prior to a private browsing session will result in a null return value.

In contrast, Chrome and Opera will return items that were set prior to the start of a private (“incognito”) browsing session, but during that session, localStorage will behave like sessionStorage, i.e., only items set during that session will be accessible. However, localStorage will function like localStorage for other private windows and tabs.

Firefox behaves similarly to Chrome in that it will not retrieve items set on localStorage prior to the start of a private browsing session. During private browsing, it treats localStorage like sessionStorage for non-private windows and tabs, but like localStorage for other private windows and tabs.

Security

Web Storage is easily accessible via JavaScript on the same domain. This implies that any JavaScript code running on a website can potentially gain access to web storage, making it vulnerable to Cross-Site Scripting attacks. This vulnerability can be exploited by attackers to:

• Steal all data stored in Web Storage.
• Inject malicious data into Web Storage.

If you choose to utilize Web Store, it’s important to be aware that harmful data can potentially be injected into web storage through JavaScript. Therefore, any application using this platform must implement measures to handle untrusted data appropriately. For example, in the event that a user is deceived by a phishing attempt and clicks on the link below:

1

javascript:window.localStorage.setItem('my-data','<iframe src="https://malicious.com/code.html"/>')

Other issues associated with Web Storage include:

• Third-party JavaScript code included on a website can also access Web Storage, creating additional security concerns.
• Any authentication mechanism that relies on Web Storage can be bypassed by a user with local privileges on the machine where the data is stored.
• Web Storage does not have a way to restrict the visibility of an object to a specific path, unlike cookies e.g. a third party markeding app on example.com/app can access anything from example.com/.
• Web Storage is not encrypted on the client side, and some browsers may even commit sessionStorage to disk.
• localStorage does not expire, and data saved in it may remain on a user’s computer indefinitely, which can raise privacy concerns.
• Any WebDatabase content stored on the client side is vulnerable to SQL injection and requires proper validation and parameterisation.
• Older browser are known to not associate Web Storage with the protocol, making HTTP/HTTPS shared context.
• The use of Web Storage to store personal data can potentially lead to privacy and compliance issues.

Encrypt data

It is feasible to perform encryption on the client-side, but it would require the user to input a password each time encryption or decryption is needed. However, the client-side JavaScript operates in an untrusted environment where the cryptographic procedures may not be entirely trustworthy.

Encrypting on the server side is the safest approach, but then the client code cannot read or update it, and so you have reduced your localStorage to a simple cookie.

Performance

The localStorage calls are synchronous.

The Dos and Don'ts of Web Storage

How will your application behave when retrieving any data from localStorage?

Dos:

• Treat all data read from localStorage or sessionStorage as untrusted user input.
• Validate, encode, and escape data read from localStorage or sessionStorage before rendering it on the page (DOM).
• Validate, encode, and escape user input before placing it into localStorage or sessionStorage.

Don'ts:

• Store sensitive or personal data in Web Storage, as it is not a secure storage solution.
• Use Web Storage data for access control decisions or rely on the JSON objects stored in Web Storage for any logic.
• Render stored data on the page (DOM) using a vulnerable JavaScript or library sink.