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