You may get a Storage object for the Document's origin using the localStorage property of the window (browser window object) interface; the data is preserved throughout browser sessions. In local storage, data is preserved for a very long period (with no expiration date.). Depending on the developer's taste, this may be one day, one week, or even one year ( Data in local storage maintained even if the browser is closed).
The benefit of the data persistance is what's causing the issue. What and how we handle it will depend on what we keep.
Downside of Localstorage
The majority of local storage's drawbacks aren't really significant. You may still not use it, but your app will run a little slower and you'll experience a tiny developer inconvenience. Security, however, is distinct. Knowing and understanding the security model of local storage is crucial since it will have a significant impact on your website in ways you might not have anticipated.
Local storage also has the drawback of being insecure. In no way! Everyone who stores sensitive information in local storage, such as session data, user information, credit card information (even momentarily! ), and anything else you wouldn't want shared publicly on social media, is doing it incorrectly.
The purpose of local storage in a browser for safe storage was not intended. It was intended to be a straightforward key/value store for strings only that programmers could use to create somewhat more complicated single page apps.
What's the most dangerous thing in the entire world?
Think about it like this: when you store sensitive information in local storage, you're essentially using the most dangerous thing in the world to store your most sensitive information in the worst vault ever created: not the best idea.
What the problem really boils down to is cross-site scripting attacks (XSS). I won't bore you with a full explanation of XSS, but here's the high level:
- Links to bootstrap
- Links to jQuery
- Links to Vue, React, Angular, etc.
- Links to any ad network code
- Links to Google Analytics
- Links to any tracking code
- Some npm packages
Let's say your website has the following script tag embedded inside it:
In this case, if somejslibrary.com is compromised and their minified.js script gets altered to:
- Loop through all data in local storage
- Send it to an API built to collect stolen information
then you are completely screwed. In this situation the attacker would have easily been able to compromise anything you had stored in local storage and you would never notice. Not ideal.
So to err on the side of caution and dramatically reduce your risk for a security incident: don't store anything sensitive in local storage.
Don't Store Tokens in Local Storage
Although I believe I made it clear in the preceding section that you should never, ever save sensitive information in local storage, I feel the need to expressly include JSON Web Tokens (JWTs).
I believe that those of us who save JWTs (session data) in local storage are the worst security violators right now. Many people are unaware that JWTs and username/password combinations are practically the same.
If a hacker manages to obtain a copy of your JWT, they are able to send requests to the website on your behalf without your knowledge. Never save your JWTs in local storage, just as you wouldn't with a credit card information or password.
Local storage is synchronous: LocalStorage is synchronous It blocks the execution of the main thread until the operation is complete, which has a negative effect on the performance of an application, especially when there are many operations.
LocalStorage can only contain strings: However, the data can be serialized with JSON.stringify: localStorage.setItem(key, JSON.stringify(object));
LocalStorage is limited to only 5MB (across all major browsers)
This may seem like a huge limit for storing strings, but there are certain types of applications that need to store a lot of data to support offline mode, etc.
LocalStorage is not accessible from the Web or Service Workers
If the application uses different Workers, the data stored in Local storage cannot be accessed within the Worker.
On a developer machine these issues can look deceptively minor as the operating system cached these requests – for an end user on the web they could mean a few seconds of waiting during which the web site stalls
LocalStorage is persistent. If you don’t use a service or never visit a web site again, the data is still loaded when you start the browser
- Credit card info
- JWT tokens
- API keys
- Personal info
- Session ids
Do not use the same origin for multiple web applications. Instead, use subdomains since otherwise, the storage will be shared with all. Reason is, for each subdomain it will have an unique localstorage; and they can't communicate between subdomain instances.
Once some data are stored in Local storage, the developers don’t have any control over it until the user clears it. If you want the data to be removed once the session ends, use SessionStorage.
Validate, encode and escape data read from browser storage
- Encrypt data before saving
Did you find this article valuable?
Support Make Reading by becoming a sponsor. Any amount is appreciated!