Menu
My team is considering using IndexedDB to cache data across user sessions. This data can be large enough that it would be a real performance boost to be able to keep it around in the browser for later use instead of having to download it every time the user needs it.
I am concerned about security problems with IndexedDB. The data in question isn't super sensitive, but there is a reason we require a user/pass to get to it. I worry that this data might be accessible if a user's laptop were stolen. Are these files sitting around unencrypted on the file system?
661
It can be configured to encrypt all the data of a table, or you may select fields to encrypt or leave unencrypted. Fields can be any data type that can be added to IndexedDB, but must be top level fields.
The short answer is IndexedDB is vulnerable to malware and physical takeover attacks. It's better than many options because cryptography is done outside the browser execution environment, but it's not totally secure.
Your web browser creates a session key, encrypts it with the server's public key and sends the encrypted key to the server. The server uses its private key to decrypt the session key. The client and server use the session key to encrypt all further communications.
As of 2022, IndexedDB is persistent type of data storage. Thus, it is evicted if the user chooses to. So, If user logs off and log back in again, then user can access data as before logs off.
You can encrypt before storing into indexeddb. That is how I do in my open source library, http://dev.yathit.com/ydn-db/doc/usage/encryption.html
One thing to note, encrypted database cannot be query. You can only retrieve with known primary key.
You still need to pass encryption key from the server after user login.
177
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
