如果这是本机应用程序，您可以尝试以下操作，

1. 在您的应用程序包中存储访问密钥。除了应用程序所有者（您自己）之外，没有人可以拥有这个。
2. 更改您的 API，以便只有在标头中设置了访问密钥的请求才会成功。
3. 使用 HTTPS，这样任何人都无法读取加密的访问密钥。

如果您不使用 HTTPS，您仍然可以在标头中手动对访问密钥进行哈希处理（只有您的服务器和应用程序逻辑知道如何操作），这样中间的人就不能假装是您的应用程序。

如果这是针对纯网络应用程序，

我首先建议将纯 Web 应用程序包装在本机应用程序（也称为混合应用程序）中，以便您可以通过在应用程序中捆绑密钥来实现上述保护。开发一个内部只有一个 Web 视图的原生应用程序不应该花费太多。

但是，如果这是不可能的，那么您的应用程序仍然是一个纯网络应用程序 - 这是一个潜在的选择，

1. 当服务器为 Web 应用程序提供服务时，提供访问密钥。
2. 当 Web 应用程序进行 API 调用时，它需要提供访问密钥的散列版本。
3. 您的 Web 应用程序如何散列取决于在缩小+混淆代码中实现的逻辑。
4. 然后，您的后端 API 通过对存储的访问密钥应用相同的隐藏逻辑来验证哈希值，以计算哈希值并查看它是否匹配。
5. 您可以根据需要频繁更改隐藏逻辑和访问密钥，以减少某人获得正确哈希的机会。

这当然不是万无一失的，但如您所知，没有完美的安全性，这可能达到目的（并希望符合要求）。不过，我想说混合动力更具成本效益。

想到的第一个想法是使用会话或在您的页面上设置一些东西来记录传入连接的 IP，并且只允许 REST API 响应最近访问您的主页的 IP。这不会阻止所有情况，但这确实意味着必须至少定期访问主站点才能使用 REST API。

但从根本上说，如果用户不需要进行身份验证，那么没有什么可以阻止屏幕抓取工具有效地从您的站点提取数据。业务规则应该由 REST API 强制执行，因此 REST API 应该有效地成为您的网站，并且使用它的页面应该只是为显示提供格式。

这可能会有所帮助。您可以做很多事情来确保您的休息服务。一种是 CORS 并使用 PUT/Delete，因为这些标头不能跨域设置。 http://www.nsa.gov/ia/_files/support/guidelines_implementation_rest.pdf