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.
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.setInterval with string arguments are aliases for
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.