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.
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.
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.
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.
- Steal all data stored in Web Storage.
- Inject malicious data into Web Storage.
Other issues associated with Web Storage include:
- 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.
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.
The localStorage calls are synchronous.
The Dos and Don'ts of Web Storage
How will your application behave when retrieving any data from localStorage?
- 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.
- 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.