什么是 API 安全？

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

API 的目标是促进您的系统和外部用户之间的数据传输，通常是私有的。因此，维护不善且不安全的 API 是打开敏感数据的大门。

成功的 API 黑客攻击影响了Facebook、Venmo、Twitter甚至美国邮政服务等企业。为了远离此列表并保护您的敏感数据，您需要将 API 安全原则集成到您的规划和构建过程中。

为什么 API 安全很重要

虽然网络安全是一个涵盖所有在线技术的广泛主题，但 API 提出了独特的挑战，因为它们介于第三方开发人员和公司资源之间。API 安全漏洞对应用程序及其用户尤其有害，因为被黑的端点授予对敏感信息的直接访问权限。

很难夸大一次成功攻击的潜在影响。虽然财务影响可能很大，但对您的品牌的损害可能无法弥补。您肯定会失去客户的信任，以及使用您的 API 的公司的信誉。第三方集成应用程序甚至可能会受到扩展程序的损害。

API 网络攻击的类型

以下是您应该了解的针对 API 的最常见攻击：

被盗身份验证

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

中间人攻击

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

代码注入

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

拒绝服务攻击

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

尽管存在这些风险，API 不会很快消失。实际上，任何寻求与他人集成的在线应用程序都需要一个或多个 API，而每个新的 Web API 都为黑客提供了另一个利用个人数据的机会。因此，任何监督软件集成的人都应该了解适当的特定于 API 的安全措施。

API 安全最佳实践

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

这就是为什么以下提示是通用的并且适用于任何实现REST API 的应用程序的原因。REST API 通过超文本传输协议 (HTTP) 传输数据，与用于将 HTML 文档发送到浏览器（我们将其视为网站）的方法相同。许多公共 API和内部 API（例如在微服务中使用）都使用这种类型的架构。Netflix、Uber 和 Trello 只是少数使用 REST 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 请求并建立配额。

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

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

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

7. 记录 API 活动。

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

这就是为什么记录所有 API 活动至关重要的原因 - 如果攻击者违反了您的保护措施，您可以评估他们做了什么以及他们是如何进入的。 .

8. 进行安全测试。

不要等到真正的攻击来看看你的保护措施如何。相反，要留出充足的时间进行安全测试，在测试中您会故意破解 API 以暴露漏洞。请记住：测试不是一个一劳永逸的过程——它应该定期执行，尤其是当您的 API 更新时。

下面让我们仔细看看这一步。

API 安全测试

API 安全的第一步是确保您的 API 按预期工作。这意味着通过 API 客户端提交正常请求并确保它们遵守上述原则。开发回答以下问题的场景：

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

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

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

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

一旦确定您的 API 正常工作，您将需要在适当的测试环境中模拟针对您的系统的代码注入、MITM、DoS 和窃取密码攻击。在您的测试中解决以下问题：

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

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

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

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

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

以下是您可以运行的一些特定测试。

用户认证测试

如果身份验证机制实施不正确，攻击者可能会破坏身份验证令牌或利用实施缺陷来冒用其他用户的身份并获得对您 API 端点的访问权限。

要测试您的身份验证机制，请尝试在没有正确身份验证（没有令牌或凭据，或不正确的）的情况下发送 API 请求，并查看您的 API 是否以正确的错误和消息进行响应。

参数篡改测试

要运行参数篡改测试，请尝试 API 请求中无效查询参数的各种组合，看看它是否以正确的错误代码响应。如果没有，那么您的 API 可能有一些需要解决的后端验证错误。

注射测试

要测试您的 API 是否容易受到注入，请尝试在 API 输入中注入 SQL、NoSQL、LDAP、OS 或其他命令，并查看您的 API 是否执行它们。这些命令应该是无害的，如重启命令或 cat 命令。

未处理的 HTTP 方法测试

大多数 API 都有各种用于检索、存储或删除数据的 HTTP 方法。有时，默认情况下 Web 服务器会允许访问不受支持的 HTTP 方法，这会使您的 API 容易受到攻击。

要测试此漏洞，您应该尝试所有常见的 HTTP 方法（POST、GET、PUT、PATCH 和 DELETE）以及一些不常见的方法。例如，尝试使用 HEAD 动词而不是 GET 发送 API 请求，或者使用诸如 FOO 之类的任意方法发送请求。您应该会收到错误代码，但如果您收到 200 OK 响应，则您的 API 存在漏洞。

模糊测试

模糊测试应该是 API 安全审计过程的最后步骤之一。这种类型的测试需要将您的 API 推到极限，以便发现任何尚未揭示的功能或安全问题。

为此，请发送大量随机请求，包括 SQL 查询、系统命令、任意数字和其他非文本字符，并查看您的 API 是否响应错误、是否错误地处理任何这些输入或崩溃。这种类型的测试将模拟溢出和DDoS 攻击。

API 管理器或网关工具将处理或帮助解决上述 API 安全指南（包括测试）。下面让我们仔细看看这些工具。

API安全管理

借助 API 管理平台，您可以在一个地方保护跨环境和供应商的所有 API 和端点。您还可以通过分配预配置的安全身份验证配置文件、创建和自定义可用于保护所有 API 或单个 API 的策略等，自动执行部分 API 安全流程。

可以说，API 管理平台最重要的功能是访问控制。他们应该防止未经授权的用户获得对您的 API 服务和数据的不当访问级别。

为了实施访问控制，大多数 API 管理平台至少支持下面概述的一种或所有三种类型的安全方案：

API 密钥：提供唯一身份验证信息的单个令牌字符串。

基本身份验证：提供唯一身份验证信息的两个令牌字符串解决方案，如用户名和密码。

OpenID Connect (OIDC)：OAuth 框架之上的一个简单的身份层，它通过获取基本的个人资料信息来验证用户，例如，使用身份验证服务器。

要发现一些可以帮助您保护 API 的流行 API 管理平台，请查看什么是 API 网关及其工作原理？[+最佳服务提供商]。

这篇博文的重点是 REST API，因为它们目前约占 API 的83%，但任何 API 都存在安全漏洞的风险。这就是为什么我们将讨论 REST API 安全性与另一种常见 API 类型的安全性之间的主要区别：SOAP。

REST API 安全性与 SOAP API 安全性

软件开发人员可能会遵循不同的架构来构建 API。最流行的是具象状态传输 (REST) 和简单对象访问协议 (SOAP)。

REST API 通过超文本传输协议 (HTTP) 传输数据，而 SOAP 以XML（一种用于存储和传输信息的常用标记语言）对数据进行编码，并通过 HTTP 发送数据。

SOAP 的要求比 RESTful 设计更严格，这使得这种类型的 API 更难构建。然而，与其他 API 设计相比，它也往往更安全，更擅长保持数据完整性。

让我们在下面分解它们的差异。

RESTful API 安全

RESTful 协议支持 SSL 以在传输时保护数据，但它缺乏内置的安全功能，包括错误处理。它也不支持 Web 服务 (WS) 规范，因此您不能使用 Web 服务安全等安全扩展来实现企业级安全。

这意味着 REST API 的安全性取决于 API 本身或 API 网关的设计。

SOAP API 安全性

与 RESTful 一样，SOAP 协议也支持 SSL 以在传输时保护数据，但它更进一步。它不仅包括 SAML 令牌、XML 加密和 XML 签名（基于 W3C 和 OASIS 建议），它们有助于保护 SOAP API 发送和接收的数据——它还支持 Web 服务 (WS) 规范。

这使您可以使用安全扩展，例如用于企业级安全的 Web 服务安全和提供内置错误处理的 WS-ReliableMessaging。

通过保护您的 API 来保护您的用户

当谈到 API 和安全性时，很容易陷入行话中。但是，请记住，这项工作的根本是保护您的用户的责任——这延伸到那些将他们的数据委托给您的人，以及使用您的 API 的开发人员。

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