this is for holding javascript data
Alec Aivazis edited A_New_Application_Architecture_Brings__.html
over 8 years ago
Commit id: 0457d72372a836b6f31a044b7b74ce015068603d
deletions | additions
diff --git a/A_New_Application_Architecture_Brings__.html b/A_New_Application_Architecture_Brings__.html
index 3cbed8c..61f49ac 100644
--- a/A_New_Application_Architecture_Brings__.html
+++ b/A_New_Application_Architecture_Brings__.html
...
id="auto-label-section-614146" class="ltx_title_section">A New
class="ltx_title_section">New Application Architecture Brings New Vulnerabilities
It's Vulnerabilities
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 is a different type of network vulnerability than the traditional three (
xss,
csrf, and
man in the middle) that arises due to the nature of SPAs. Previous paradigms did not have this problem because they could authenticate every request using traiditional methods 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.