I'm sort of new to Frontend programming. I'm trying to build a PWA, it stores data (client data i.e: address, name, phones) to be ready in an offline state, for which I'm using localForage. I've realised that all data stored in the browser is readable/writable by anyone (event when not logged in, as the browser's debug tool allows you to see the site's IndexedDB or WebSQL). So logically I'm now encrypting/decrypting data when storing/retrieving it, btw I'm using CryptoJS (AES with a 63 bit password). That solves that (at least for now, recomendations welcome). Now to the issue:

  • AES password can be search and found using a browser's debug tool.
  • Obfuscating the file/password is just wasted time and performance.
  • Retrieving the password from a server is pointless as the XHR request can be debugged.

Is there no workaround this?


I'm not concerned about a legit user from accesing this data. I'm concerned about bots, malicious browser extensions, or other kinds of attacks that can read the storage by just visiting site. Not sure how likely or if this is even an attack vector.

Seems like I took too much time into thinking about this and it will be wasted time.

2 Answers 2


You've basically covered the reasoning's behind why you don't bother encrypting items sitting on the end users devices, they need access to the data else you wouldn't be sending it to them and any method of encrypting/decrypting would need to be accessible on the frontend to make the data readable so the encryption type and password would always be available in some way.

  • As a new user you cannot upvote. This privilege is granted starting at 15 rep. But you can accept one answer by checking the mark. Commented Nov 4, 2021 at 15:59

You many want to consider using the Web Crypto API, and storing a private key for the user in a CryptoKey object, which you can then store in the browser's IndexedDB storage. If you set the .extractable property to false on the CryptoKey object, then the private key can only be used for decrypting messages, signing messages, or deriving shared secrets - but the private key can not be read (even by client-side scripting in the browser).

See https://crypto.stackexchange.com/questions/35530/where-and-how-to-store-private-keys-in-web-applications-for-private-messaging-wi for more info.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .