Because of this it's clear that we need to have a way of viewing the local authentication data for use by the application logic. However, special care needs to be made to prevent someone interacting with the developers console to be able to change the local authentication data in order to gain access to restricted parts of the code by elevating their permissions. This highlights another reason not to use global variables.  This is a different type of network vulnerability than the traditional three (href="http:">xss, csrf, href="https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting">xss, csrf,  and href="http:">man href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">man  in the middle) that arises due to the nature of SPAs. Previous paradigms did not have this problem because they could authenticate every GET request and prevent the user from going somewhere they shouldn't. Even if one were to have a solution for this (in light of the malicious browser), we would still still authenticate backend endpoints to prevent data from leaking. The client can never be trusted and performing crypto on the browser is a bad idea. However, we need a quick way to authenticate frontend routing logic that is truthworthy.