我有两台服务器，一台负责前端应用程序和用户身份验证。该服务器正在呈现一个用 javascript 编码的单页应用程序。此 javascript 应用程序正在通过第二台服务器上托管的 REST api 从第二台服务器呈现数据。
我想保护这第二台服务器。我希望只有前端应用程序能够调用后端服务器。
目前任何人都可以从浏览器调用rest api来查询数据。
感谢您的帮助。
【问题讨论】：
标签： api security rest restful-authentication restful-architecture
javascript 应用程序可以在浏览器客户端执行的任何操作都可以被其他人看到并由其他人执行，以访问您的应用程序外部的后端 REST API 服务器。
实际上，客户端应用程序是用 JavaScript 实现的这一事实无关紧要 - 任何在您无法控制的机器上执行的应用程序都不能被完全信任。对可执行的本机代码进行逆向工程比在 javascript 应用程序上查看源代码要困难一些，但并非不可能。永远不要依赖默默无闻的安全性。
您的最佳选择是让浏览器应用程序要求最终用户登录并从受信任的身份提供商处获取身份验证令牌，并在浏览器应用程序向 REST API 发出的每个请求中提供该身份验证令牌。然后，REST API 可以验证身份验证令牌，以查看它是否来自受信任的提供者，以及令牌内命名的用户是否被授权使用 REST API。
这将 REST API 调用的授权绑定到用户而不是应用程序，并利用不存在于浏览器应用程序中的秘密（用户凭据）供全世界查看。
有了这个，您可以根据发起调用的用户来限制对 REST API 的访问。您仍然可以根据发出请求的应用程序过滤访问权限，但这应该是次要的，而不是主要的安全因素，因为复制应用程序描述比复制用户凭据更容易。
另一种选择可能是让您的 Web 服务器充当 REST API 服务的代理，以便浏览器应用程序必须通过 Web 服务器才能从 REST API 获取数据。如果浏览器应用程序维护 Web 服务器可以验证的会话状态以确定请求来自真正的应用程序而不是来自其他人，这可能是可行的。虽然这可能允许您将 REST API 保持在公共网络之外，但它并没有真正改变您的授权问题 - 您只是将其移动到 Web 服务器，您可能有更多会话上下文来区分应用内请求一个闯入者的请求。充其量是脆弱的，除非您对自己的应用会话状态非常有信心，否则不推荐使用。
无论您选择哪种解决方案，事实仍然是，如果您的 REST API 可以从客户端应用程序（浏览器或其他方式）访问，那么它就是一个公共 REST API，应该被这样对待（和强化）。没有可以从客户端计算机访问的私有 Web API 这样的东西。
【讨论】：