- There is no way to guarantee the browser itself is not compromised.
- Without SSL/TLS, there is no way to guarantee the data or code loaded by the browser was that provided by the server.
You can encrypt data on the server then send the data to the client over SSL/TLS. However, once the data is there, you need something to decrypt it, which requires storing the key. Unfortunately, there is no way to securely store the key. Neither local storage nor browser specific systems, e.g. chrome.storage, are encrypted.
There are other options, including ActiveX controls, Java applets, Adobe AIR or Adobe Flash apps. Unfortunately, all of these come either their own security issues or are platform specific. You could write browser plug-ins but these are also browser and sometimes platform specific.
This data is sensitive and must be secure
How secure is it? Convenience or functionality usually trumps security so you will likely have to consider the trade offs, such as:
- Can you store some of the data and not the more secure parts? For example, if you are storing customer contact details, cache data that is not Personally Identifiable Information (PII, such as US social security numbers).
- Can you require a certain browser or platform? For example, if most of your customers use Windows, consider an ActiveX control or a ClickOnce desktop application. If they use Windows 8+, can you create an app on the Windows app store (as much as this suggestion may make some shudder)?
- Does the data change frequently, so the impact of a compromise is small?
Also remember that secure storage is not the only thing to consider. Even if you solve this issue, there is no point storing data securely if it is not delivered over SSL/TLS (so it can be viewed or tampered with in transit) or if you use weak or poor authentication (e.g. unencrypted and unhashed authentication cookie). Similarly, given physical access to the storage medium, there is no way to protect the data from a determined, patient attacker even if it is encrypted.