我的理解是，如果您将登录页面包含在SPA中，那么用户将在甚至通过身份验证之前收到您的所有代码。但是，这似乎是非常普遍的做法。这不是非常不安全吗？为什么或为什么不呢？
答案 0 :(得分：3)
SPA将具有所有页面结构（用于页面设计的html和javascript代码），但显然没有数据。数据将在后续的ajax请求中下载，这就是重点。要下载实际数据，必须向服务器验证用户身份，然后在服务器端实现所有安全性。未经授权的用户不应能够从服务器访问数据。但是想法是页面的外观不是秘密，任何人都可以看看SPA 没有数据的页面，这很好。
好吧，这是人们经常忽略的问题。 HTML是一回事，但是SPA中的所有javascript都可以访问所有数据。基本上，SPA的代码是一个API文档（如果您愿意），是后端可以处理的可能查询的列表。当然，应该在服务器端都是安全的，但并非总是如此，人们会犯错误。有了SPA这样的“文档”，攻击者可以更容易地评估服务器端的安全性并在服务器端代码中查找授权/访问控制缺陷，从而可以访问不应被访问的数据攻击者。
因此，简而言之，访问页面外观（无数据）应该没问题。但是，在某些情况下放弃API的确切工作方式可以帮助攻击者，因此会增加SPA固有的风险。
尽管没有关系，但必须注意。由于不应使用默默无闻的安全性（即，工作方式不应成为秘密，只有凭据之类的事情才应该是秘密），因此最好让任何人都知道所有JavaScript或完整的API文档。但是，现实世界并不总是那么理想化。攻击者通常不知道这些东西是如何工作的，并且能够例如分析SPA确实有帮助，因为编写后端代码的人确实会犯错误。在其他情况下，API是公开的，并且无论如何都要进行记录，在这种情况下，拥有SPA不会带来进一步的风险。
如果您将SPA放在身份验证后面（只有经过身份验证的用户才能下载SPA代码），尽管我认为某些内容分发网络确实支持某种级别的身份验证，但这会使CDN访问变得非常复杂。
但是，在SPA之外拥有一个单独的（纯旧html）登录页面确实有好处。如果您在SPA中有登录页面 ，则只能在javascript中获取访问令牌（会话ID，无论如何），这意味着javascript可以访问它，并且只能将其存储在localStorage中，或非httpOnly的纯Cookie。这很容易导致身份验证令牌通过跨站点脚本（XSS）被盗。一个更安全的选择是拥有一个单独的登录页面，该页面将身份验证令牌设置为httpOnly cookie，任何javascript都无法访问它，因此可以安全地使用XSS。请注意，尽管这样做会带来CSRF的风险，您需要处理CSRF，而不是像请求标头那样发送令牌/会话ID。
在许多情况下，可以在SPA中进行登录并将身份验证令牌存储在localStorage中，但这是一个明智的决定，并且您应该意识到这种风险（在其他情况下为XSS与CSRF）。
答案 1 :(得分：1)
很明显，必须通过authn在API之后保护加载到SPA中的数据的安全。但是我认为您也可以确保布局安全，因此可以访问页面外观。通过元模型驱动的开发，您可以从安全的API提供布局配置。我不是在提供HTML（即SSR），而是在提供JSON。布局配置不过是服务器上定义屏幕内容（全部或部分）的JSON文件。然后，您的SPA代码变成该元模型的通用解释器/呈现器，用于解析有效负载，呈现组件并绑定数据。如果您的API是L3，voilà，那么您将获得一个完全可用的API驱动的应用。