什么是 API 安全？

API 安全是保护 API 免受网络攻击和滥用的做法。适当的 API 安全措施可确保对 API 的所有已处理请求均来自合法来源，所有已处理请求均有效，来自 API 的所有响应均受到保护，不会被拦截或利用。

实际上，任何寻求与他人集成的在线应用程序都需要一个或多个 API，而每个新的Web API 都为黑客提供了另一个利用个人数据的机会。因此，网站软件从业人员都应该了解适当的特定于 API 的安全措施。

API 网络攻击的类型

被盗身份验证

访问 API 的最简单方法之一是劫持授权用户的身份。例如，如果身份验证令牌落入坏人之手，它可以被用来访问具有恶意意图的资源，同时看起来是合法的。网络犯罪分子还会尝试猜测身份验证密码或破坏弱身份验证过程以获取访问权限。

中间人攻击

当黑客拦截最终用户和 API 之间的 API 请求或响应时，就会发生中间人 (MITM) 攻击。他们可能会窃取此通信的敏感内容（例如帐户登录凭据或付款信息）或修改请求/响应的内容。

代码注入

在身份验证和验证方面存在差距的 API 也容易受到代码注入的影响，其中攻击者通过 API 请求将脚本发送到应用程序的服务器。此脚本旨在公开或删除数据、植入虚假信息和/或损害应用程序的内部结构。您还将看到使用的术语“SQL 注入”，这是对SQL 数据库执行的代码注入。

拒绝服务攻击

拒绝服务 (DoS) 攻击会通过 API 请求来使 Web 服务器变慢、中断或崩溃，从而使服务器的资源不堪重负。通常，这些攻击同时来自多个来源，分布式拒绝服务 (DDoS) 攻击。

API 安全最佳实践

虽然任何拥有 API 的组织都可以成为目标，但每个组织都会以不同的方式实施 API 和 API 安全性。提供支付信息访问权限的 API 需要比图像共享服务更多的预防措施。

通过遵循这些指南，您将大大降低与维护 API 相关的风险，无论您属于哪个领域。

1. 实施认证

在处理请求之前，API 执行身份验证，它需要验证发送请求的用户或程序的身份。

通常，API 使用密码、多重身份验证和/或身份验证令牌进行身份验证，身份验证令牌是用作用户唯一标识符的字符串。要使用令牌对请求进行身份验证，API 会将请求中发送的令牌与其数据库中存储的令牌进行匹配。令牌可帮助组织跟踪对其资源信任的人。

今天，OAuth协议是 API 用户身份验证的广泛接受的标准。OAuth 最初是为社交登录而设计的，允许用户使用密码登录第三方应用程序而不会泄露他们的密码。例如，OAuth 允许我使用我的 Google 密码登录到 LinkedIn 等第三方网站，而无需 LinkedIn 存储我的密码。

OAuth 建立在 HTTP 之上，这也使它非常适合 REST API。虽然 OAuth 的内部运作超出了本文的范围，但在基本层面上，OAuth 为 API 管理员提供了一种向已批准的第三方授予身份验证令牌的方法。管理员可以设置自定义访问规则，根据请求的来源确定允许哪些 API 请求。

2. 实施授权

在验证发送请求的用户的身份后，API 需要一种方法来仅授予对授权资源和方法的访问权限。例如，用户可能被批准访问 API，但如果不允许他们通过 POST 方法向应用程序的数据库添加信息，则应拒绝任何这样做的请求。授权信息也可以作为令牌包含在请求中。

与其他一些 API 类型不同，REST API 必须对向服务器发出的每个请求进行身份验证和授权，即使多个请求来自同一用户。这是因为 REST 通信是无状态的，也就是说，API 可以孤立地理解每个请求，而无需来自先前请求的信息。

授权可以由用户角色管理，每个角色都有不同的权限。通常，API 开发人员应遵循最小权限原则，即用户只能访问其角色所需的资源和方法，仅此而已。预定义的角色可以更轻松地监督和更改用户权限，从而减少不良行为者访问敏感数据的机会。

3. 验证所有请求

如上所述，有时来自完全有效来源的请求可能是黑客尝试。因此，API 需要规则来确定请求是友好的、友好但无效的还是有害的，例如尝试注入有害代码。

API 请求只有在其内容通过彻底的验证检查后才会被处理，否则，该请求将永远不会到达应用程序数据层。

4. 加密所有请求和响应

为防止 MITM 攻击，从用户到 API 服务器或从用户到 API 服务器的任何数据传输都必须正确加密。这样，如果没有正确的解密方法，任何被拦截的请求或响应对入侵者都是无用的。

由于 REST API 使用 HTTP，因此可以通过使用传输层安全性 (TLS) 协议或其之前的迭代安全套接字层 (SSL)协议来实现加密。这些协议在“HTTPS”（“S”意为“安全”）中提供 S，并且是加密网页和 REST API 通信的标准。

TLS/SSL 仅在传输数据时加密数据。它不会加密位于 API 后面的数据，这就是敏感数据也应该在数据库层加密的原因。

5. 只在回复中包含必要的信息

就像您在向朋友讲述故事时无意中泄露了秘密一样，API 响应可能会暴露黑客可以使用的信息。为防止这种情况，发送给最终用户的所有响应应仅包含用于传达请求成功或失败的信息、请求的资源（如果有）以及与这些资源直接相关的任何其他信息。

换句话说，避免“过度共享”数据，响应是您无意中暴露私人数据的机会，无论是通过返回的资源还是详细的状态消息。

6. 限制 API 请求并建立配额

为了防止像 DoS 这样的蛮力攻击，API 可以施加速率限制，这是一种在任何给定时间控制对 API 服务器的请求数量的方法。

有两种主要的方式来限制 API 请求的速率，配额和节流。配额限制用户在一段时间内允许的请求数量，而节流会减慢用户的连接速度，同时仍允许他们使用您的 API。

这两种方法都应该允许正常的 API 请求，但可以防止大量的流量造成破坏，以及一般的意外请求峰值。

7. 记录 API 活动

到目前为止，我们已经介绍了用于应对 API 威胁的抢占式方法。但是，在成功入侵您的系统的情况下，您需要一种方法来跟踪事件的来源，以便您可以纠正和报告问题。

这就是为什么记录所有 API 活动至关重要的原因，如果攻击者违反了您的保护措施，您可以评估他们做了什么以及他们是如何进入的。如果不出意外，您可以使用攻击来进一步强化您的 API，从而可能防止将来发生类似事件.

8. 进行安全测试

不要等到真正的攻击来看看你的保护措施如何。相反，要留出充足的时间进行安全测试，在测试中您会故意破解 API 以暴露漏洞。

这意味着首先通过 API 客户端提交正常请求，并确保它们遵守上述原则。开发回答以下问题的场景：

只有经过身份验证的用户才能访问您的端点吗？

用户是否仅根据其角色被授予访问必要端点的权限？

每个潜在请求的响应中是否返回了正确的信息？

良性但无效的请求是否被拒绝？

您还需要在适当的测试环境中模拟针对您的系统的代码注入、MITM、DoS 和窃取密码攻击。在您的测试中解决以下问题：

我的身份验证可以反击蛮力输入尝试吗？

我的 API 如何处理请求中的显着峰值？

如果经过身份验证的用户通过请求提交有害脚本或文件怎么办？

所有数据传输都加密了吗？是否禁止不使用 TLS/SSL（即使用 HTTP 而不是 HTTPS）的请求？

如果请求或响应被拦截怎么办？我的 API 和用户如何知道？

API 技术为在线应用程序带来了无数的可能性，但安全事件可能会很快使您从 API 中获得的任何好处黯然失色。虽然不可能消除所有威胁，但上述原则对于任何关心其声誉，更重要的是其客户的组织而言都是必要的。