Authenticating Route Transitions in an SPA: What to do About the Developer Console  

In a single page app, all of the decisions about what view/subview to render occurs on the client. This means that ideally the client would be able to authenticate the currently logged in user on transitions to sensitive pages and access its data without going back to the server. This means that special care needs to be made to protect our application from a malicious user interacting with the developer console present in all modern browsers. One possible security vulnerability is the escalation of a globally stored user user role. This would cause the hacker to view a part of the website that they were forbidden to.
This blog post summarizes my attempts at adding an additional layer of security to my locally stored authentication information. Also, I just want to make it clear: even if a perfect solution is found for this vulnerability, server endpoints still need to verify the request. The client can never be trusted and performing crypto on the browser is a bad idea

No one is an island

Our problem is simply stated: we need a way to store the user authentication information on the client in a trustworthy manner. If we allow ourselves one connection to the client, we can authenticate the credentials and save a copy of the authentication information in a way that prevents it from being easily changed by the console. This means we have moved the crypto part off of the client and we can begin to think about trusting the data that we have stored.

JavaScript has a problem with global state. This problem is known by almost all JavaScript developers and is exacerbated by the presence of the developers console. We can assign a function that is available globally in the success handler of the xhr request which will returned the decrypted authentication information in a read-only manner. The global scope of the closure makes the unencrypted authentication data readable by anyone who requires it

More callbacks?? I like raw data types.