Off the top of my head, I can think of four ways this strategy could fail. All can be mitigated to some degree through sound development practices and commonsense on the part of users, and a few would require some very targetted attacks, but they are risks nevertheless.
Eval
Storing confidential data on the heap will be risky if you intend to use eval, because code running under eval can access variables in the scope of the eval call, which might include your heap variables. Consider:
var creditCardNumber = 123456789;
var evalString = "window.alert(creditCardNumber)";
eval(evalString); // alerts the credit card number!
There are a couple of ways a malicious user might mount an attack:
- If evalString is fished out of a database, an attacker might try and influence that data somehow
- If your application uses third party code, an attacker might try and hijack that resource and use
eval to grab the data and send it forwards (remember: code running from different scripts will still share the selfsame heap). This risk might be mitigated if the confidential data is somehow held in a closure rather than exposed directly on the heap, but such practices would be easy for a naive developer to break.
Remember that calling window.setTimeout and window.setInterval with string arguments are aliases for eval too.
Browser extensions
Browser extensions may be given the opportunity to inspect the contents of the JavaScript heap, directly or indirectly. For instance, Chrome provides a debugging API for extensions built as developer tools. Users must give permissions to use these extensions, though, and install them purposefully, so this might not be a simple way to mount an attack.
Reverse engineering
Even minified code can still be reverse engineered, so it's always possible for malicious users to reason about how you're performing encryption and the way your JavaScript application handshakes with the server.
Accidental exposure through third party code
You may be confident that your code never assigns creditCardNumber to something persistent like localStorage or serializes it to JSON and pushes it to window.name, but are you similarly confident about third party code? It might be worth checking if you're passing the object around, particularly if you're passing it to something that tries to perform caching.
