我正在开发一个项目，该项目正在创建两个新的、独立的 Web 模块（甚至可能在不同的服务器上）以支持新的 Web 应用程序，其中一个提供基于 JS 的静态 UI，另一个提供 API。API 将由角色保护，这意味着您必须登录并拥有正确的角色才能访问端点，但是我想知道保护 UI 是否有很多优点？
我不是在谈论 SSL，因为希望我们能够在这两个项目上强制执行，而是更多关于是否可以将单个大型 JS 文件转储到用户的机器上（一旦他们使用任何角色），无论他们拥有哪些角色，并依赖 API 来保护数据？
我觉得我在这里遗漏了一些基本的东西，但据我所知，唯一真正的风险是 UI 中的应用程序逻辑对所有客户都是可见的，尽管它显然会被缩小 - 因此会被混淆。
为这个稍微含糊的问题道歉……恐怕这不是我有很多经验的领域。
我认为你在正确的轨道上。只要 API 是安全的并且不允许不正确的行为，那么就没有办法操纵 UI 直接导致不良行为，至少就应用程序而言。
当您意识到从用户的角度来看 UI 不可信时，问题就开始了。如果可以操纵用户看到的内容，那么就有可能通过误导他们的输入来让他们输入不正确的信息。同样，从 UI 泄漏的信息在您的上下文中可能是也可能不是问题。
您不必担心批量漏洞利用会破坏业务规则，因为 API 不允许这样做，但您仍然对最终用户体验存在安全问题。
如果您的 API 是可靠的，那么真正的漏洞与您是否可以确定用户就是他们所说的人有关。
一种攻击向量称为跨站点请求伪造（“CSRF”或“XSRF”）。基本上，有人冒充另一个用户并向您的服务器发出请求。
当您建立会话（其中包含给定用户的角色）时，您需要确保没有其他人可以劫持该会话。这通常是通过在用户机器上设置一个“仅限 http ”的唯一 cookie （即客户端 JS 不应该能够操作的 cookie）来完成的，然后确保该 cookie 在后续请求中是相同的。
这是一个 Node 模块，旨在通过 CSRF 保护来强化 Web 服务器——以及其他安全措施——这可能值得一看：https : //npmjs.org/package/helmet
回复：特别是 API，这里有一个非常有趣的关于有人入侵 GitHub 的细分。
这可能超出了您的安全需求，但请记住，任何具有正确权限的恶意 Chrome 扩展都可能以破坏您的安全模型的方式更改客户端（通过将数据发送到异地或更改 UI，例如例子）。
从理论上讲，仅 API 是安全的就足够了，例如在典型的服务器-客户端应用程序中，用户使用他选择的客户端，如果客户端被利用，这是用户的问题。
然而，在网站的情况下，由于您提供的是客户端（Web 界面），因此您需要确保一旦用户使用 XSS 和 CSRF 等技术登录，它就不会被第三方利用。
不幸的是，一旦用户信息到达客户端计算机，您就无法有效地限制用户信息。换句话说，如果我正确理解您正在发送一个 JS 文件，其中包含您不希望用户能够阅读的代码或信息，除非他们具有特定角色，那么您将无法实现该目标. 在发送到客户端之前，您需要在服务器端过滤信息。在发送数据之前始终检查用户角色可能是一项耗时的任务。这需要对服务器进行更多调用，因为用户执行某些需要信息的任务。但我认为需要采取此类行动，以确保只有正确的用户才能访问信息。
缩小的 js 在发送给用户后并没有真正提供太多的混淆。