如何保护仅服务于我的前端的自己的后端 API？

Posted 2023-02-19

【中文标题】如何保护仅服务于我的前端的自己的后端 API？

【英文标题】：How to secure own backend API which serves only my frontend?

【发布时间】：2019-06-19 12:47:09

【问题描述】：

我正在设置一个带有前端和后端的 web 应用程序，该应用程序通过 RESTful 方法与前端单独通信。如何确保后端端点只能由我自己的前端访问，而不是其他任何人？我找不到这方面的太多信息。

【问题讨论】：

当您说前端时，您是指客户端 - 比如在浏览器中运行的 javascript 应用程序或移动应用程序之类的吗？

***.com/questions/47298148/securing-express-api 的可能重复项

【参考方案1】：

我如何确保后端端点只能由我自己的前端访问，而不能由其他人访问？

让我在这里告诉你一个残酷的事实......对于网络应用程序来说是不可能的，因为 自然网络是如何设计的。

让我们通过理解 WHO 和 WHAT 访问您的 API 服务器之间的区别，以及为什么是私有的 API 不存在。

谁和什么在访问 API 服务器

WHO 是网络应用的用户，您可以通过多种方式进行身份验证、授权和识别，例如使用 OAUTH 流和/或 OpenID。

OAUTH

通常，OAuth 代表资源所有者向客户端提供对服务器资源的“安全委托访问”。它指定了资源所有者授权第三方访问其服务器资源而不共享其凭据的过程。 OAuth 专为与超文本传输​​协议 (HTTP) 一起使用而设计，本质上允许授权服务器在资源所有者的批准下将访问令牌颁发给第三方客户端。然后第三方使用访问令牌访问资源服务器托管的受保护资源。

OpenID

OpenID Connect 1.0 是 OAuth 2.0 协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终​​用户的基本配置文件信息。

现在您需要一种方法来识别 什么 正在调用您的 API 服务器，而这里的事情变得比大多数开发人员想象的要棘手。 WHAT 是向 API 服务器发出请求的东西，它真的是您真正的 Web 应用程序还是机器人、自动脚本或攻击者使用 Postman 之类的工具手动绕过您的 API 服务器？

为了识别 WHAT 开发人员倾向于求助于 API 密钥，该密钥通常在标头、cookie 中或隐藏在其 Web 应用程序的 javascript 代码中发送，有些人会加倍努力并在运行时在 Web 应用程序中计算它，因此成为动态机密，而不是前一种方法，即嵌入在代码或标头中的静态机密。

私有 API

无论 API 是否没有可公开访问的文档，或者是否受到任何类型的机密或身份验证机制的保护，一次都可以访问 从互联网不再是私人的，因此任何人都可以访问 知道它在哪里，枚举每个端点就像使用网络一样容易 开发工具中的选项卡。

可能的解决方案

在客户端运行并且需要一些秘密才能访问 API 的任何东西 可以以不同的方式被滥用，您可以了解更多信息 this series 的 有关移动 API 安全技术的文章。虽然这篇文章在哪里完成 在移动应用程序的上下文中，它们仍然与 Web 应用程序共享通用技术。 他们将教您如何使用 API 密钥、用户访问令牌、HMAC 和 TLS 固定 用于保护 API 以及如何绕过它们。

你的 Javascript 代码可以通过混淆它变得难以理解，这将使逆向工程变得困难，但请记住并非不可能，因此不要依赖它来隐藏敏感数据，而只是作为另一层更难理解发生了什么。

您可能还想查看 Google 提供的 reCaptcha V3，它可以区分真实用户 来自自动化脚本，无需用户交互。您需要将其添加到 Web 应用程序的每个页面。

reCaptcha V3

reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用。 reCAPTCHA 使用高级风险分析引擎和自适应挑战来防止自动化软件参与您网站上的滥用活动。它在让您的有效用户轻松通过的同时做到这一点。

另一种更复杂的方法是使用用户行为分析 (UBA) 工具，该工具在后端采用机器学习和人工智能来防止 API 滥用，但它们无法 100% 阻止它。

要解决 什么 访问您的 API 服务器的问题，您需要使用关于移动 API 安全技术、reCaptcha V3 和 UBA 解决方案系列文章中提到的一个或所有解决方案并被接受他们只能使对您的 API 服务器的未经授权的访问更难绕过，但并非不可能。

总结

因此，您可以使查找和访问您的 API 变得困难，但要将其真正锁定到您的网络应用程序中，您却不能。

【讨论】：

noob 问题，您不能创建一个公钥私钥对，以便您的服务器拥有私钥并且 api 用户每次都需要在请求中发送公钥吗？并以某种方式验证它们是否匹配

你可以，但是密钥是公开的，因此任何人都可以通过reverse engineer 使用它的应用程序或通过MitM attack 获取它。

【参考方案2】：

查看 CORS。并确保您的服务器只允许访问特定来源。

在后端 - 检查请求中是否存在 X-Requested-With 标头并设置为 XMLHttpRequest。如果没有正确的 CORS 握手，此标头将不存在。

话虽如此，这只会保护您的 API 不被其他前端应用程序使用或直接从浏览器地址栏访问 - 因为浏览器尊重 CORS。人们仍然可以通过编程方式/CLI 伪造请求并将标头设置为他们想要的任何内容。

所以这实际上并不是“保护”只是一种防止滥用和盗链的方法