如今，API 是许多业务模式的基础（有时甚至是业务模式本身）。它们构成了现代应用的基本框架，并支持开发人员将软件组件嵌入到应用中，以扩展功能和增强用户体验。

API 大致可分为四种类型：

如欲了解有关 API 类型的更多信息，请参阅“API 互联”。

虽然 API 有助于快速推进应用现代化，但由于其与生俱来的开放性，它们也可能会泄露敏感数据。F5《2021 年应用保护报告》显示，近三分之二的 API 事件归咎于 API 的完全暴露（没有任何访问限制）。

在当今由 API 驱动的软件环境中，必须制定安全防护策略，将 API 防护融入开发流程中，而不是事后再进行补救。

随着大量应用通过 API 即时交付资产，快速安全防护变得至关重要。攻击者总企图利用 API 设计中的各种缺陷趁机进行不受限制的访问。与 HTTP Web 请求一样，API 调用包括 URI、方法（method）、请求头及其他容易遭到攻击的参数。

API 端点的激增是导致现代 API 生态系统的潜在攻击面扩大的一个关键原因。该现象被称为“API 蔓延”，可能会对 API 生态系统的安全构成极大威胁。构建强大安全的 API 基础设施的第一步是有效管理 API 蔓延。

API 蔓延源自数字化转型过程中出现的两个挑战：

现代微服务架构的日益普及可能会加剧 API 蔓延，因为这种架构使用大量的 API 进行接口之间（南北向流量）和微服务之间（东西向流量）的通信。

应对 API 蔓延的策略包括：

如欲深入了解这些策略以及具体实施方法，请参阅《应对 API 蔓延的五种方法（以及为何应当关注 API 蔓延问题）》。

如欲详细了解 API 端点激增的影响和相关统计数据，请参阅 F5 报告《API 持续蔓延：API 驱动型经济的挑战与机遇》。

开放式 Web 应用安全防护项目 (OWASP) 指出了 OWASP 十大 API 安全防护风险项目中最常见的 API 漏洞：

API1. 失效的对象级授权 —— 处理对象标识符的端点被暴露，造成了广泛的攻击面。

API2. 失效的用户身份验证 —— 身份验证机制实施不当，致使攻击者能够窃取身份验证令牌或假冒合法用户的身份。

API3. 过度的数据暴露 —— 开发人员经常暴露所有对象属性，使得客户端难以在数据到达用户之前执行数据过滤。

API4. 缺乏资源和速率限制 —— API 一般不会对客户端/用户的可请求资源数量（或大小）施加限制，这会导致 API 服务器性能不佳、拒绝服务攻击 (DoS) 和身份验证错误。

API5. 失效的功能级授权 —— 具有不同层级、分组和角色的复杂访问控制策略往往会导致授权问题，攻击者可利用这些问题访问其他用户的资源和（或）管理功能。

API6. 批量赋值 —— 由于基于允许列表的不正确的属性过滤，攻击者可以修改对象属性。

API7. 安全防护配置错误 —— 不完整的配置、开放的云存储、错误配置的 HTTP 请求头等配置错误会造成可利用的安全防护漏洞。

API8. 注入（Injection） —— 当不受信任的数据通过命令或查询发送到解释器（interpreter）时会产生注入漏洞（例如 SQL、NoSQL 和命令注入），以致攻击者利用这些漏洞执行非预期的命令或访问未经授权的数据。

API9. 资产管理不当 —— 由于 API 暴露了大量端点，因此需要使用适当的最新文档来防止攻击者利用漏洞。

API10. 日志记录和监控不足 —— 当日志记录、监控以及与事件响应的集成不足时，攻击者可通过进一步攻击系统和长期驻留来提取或破坏数据。

虽然人们已普遍认识到 API 安全防护的必要性，但重大的 API 攻击事件仍然时有发生。Gartner 在其《API 安全：API 保护须知》报告中强调，应用团队领导者需要设计有效的安全防护策略来保护其 API。

安全防护必须贯穿 API 生命周期的每个阶段——从设计到开发再到部署。虽然发现工具（常见于自上而下的安全防护方法中）是必要组件，但我们认为合理的 API 安全防护应始于构建和部署 API 的团队（请见下方“API 优先和 API 治理”一节）。这种应用和 API 安全防护方法被称为“左移 ”，即在软件开发生命周期 (SDLC) 的早期应用安全防护控制，并可在 CI/CD 流水线中实现自动化。

与左移相辅相成的方法是“安全右移”，后者主要采用 API 发现和 Web 应用防火墙 (WAF) 等方法来抵御网络边缘威胁。虽然安全右移是一条重要的防线，但我们认为左移对于构建设计安全的应用而言至关重要。如果您未将安全防御内置于 CI/CD 流水线并及早捕获攻击，那么就必须在攻击发生时迅速做出响应（有时需要返工补救）。

API 安全防护涉及多个团队和系统。下表列出了需要嵌入 API 安全防护的几个关键点。通过多层覆盖，您可以实现强大的安全防护。这些方法和技术通常会在 API 网关或跨一系列架构检查点实施。

访问控制

网络安全

运行时保护

描述

管理 API 端点的身份验证和授权

提供安全的网络通信，转移网络层面的恶意流量

规避常见的软件漏洞，利用 Bot 缓解技术防止 API 滥用

技术

OAuth 2.0、OpenID Connect (OIDC)、JSON Web 令牌 (JWT)、随机 API 密钥

mTLS、DDoS 防护、速率限制、加密

Web 应用防火墙、JSON 模式验证、攻击签名、异常检测

我们注意到越来越多的团队实施 API 优先开发模式。“API 优先”意味着应用设计从 API 开始，而其中的 API 被视为一种独特的基础产品。

API 优先模式的一大优势是，它简化了 API 治理，支持您全面控制和了解复杂的系统。这可帮助您确保 API 在其整个生命周期内和潜在演进过程中始终安全无虞。

注：虽然现有多种 API 治理方法，但我们建议采用自适应治理技术，它可为开发人员赋能，并为平台运维人员提供必要的控制力，以确保 API 始终安全可靠。

如果从一开始就实施妥当的治理，那么 API 会很容易被发现，无论是对使用 API 的开发人员还是对需要保护 API 的安全团队而言都是如此。但大多数企业都没有从一开始就大规模地实施高效的 API 治理。因此，他们需要对现有和新增的 API 实施 API 治理和安全防护。

随着 API 的广泛采用，出现了一个严重的问题：除了 API 作者（API 开发人员）以外，没有人知道它们的存在，API 总是悄然无声地进入生产环境中。有时，这是设计和部署过程中的疏忽。这些 API 通常被称为“影子 API”。

或者在一些情况下，相关的开发人员可能会转到其他角色或项目，导致最终甚至没有人知道这些 API 的存在。这些 API 有时也被称为“僵尸 API”——它们不受监督地运行，对企业中的每个人都隐藏不露。

自动化的 API 发现工具可帮助您全面了解当前的生态系统，包括 API 的部署位置、可能包含敏感数据的 API 以及可能存在的安全漏洞。通常情况下，发现 API 后，您可以生成并导出一个 OpenAPI 规范，从而把 API 迁移到中央 API 网关，并将其添加到开发人员门户或 API 目录。

与其他计算领域一样，随着开发人员不断寻找提高性能和可靠性的方法，API 技术在过去 25 年中发展日新月异。  API 设计理念和数据表示方法持续演进，数据和流量保护方式也随之变化。常用 API 架构的时间轴大致如下：

SOAP（1998-2010 年）  →  REST （2010 年至今）  →  GraphQL（2020 年以后）

简单对象访问协议（SOAP）的 API 使用数字签名和 XML 格式数据的加密来实施消息级安全防护。消息级安全防护通常比 REST API 架构风格的安全防护更加全面（见下一节）。然而，尽管因可移植性而备受赞誉，但消息级安全防护现在只见于传统的 Web 服务中。

过去十年，表征状态转移 (REST) 成为最常用的 API 架构风格。 如今，大多数 Web API 都是 REST API。在 REST 中，资源通过唯一的 HTTP URI 进行标识，访问控制规则则是基于 HTTP 动词和 HTTP URI 的组合。

GraphQL 是一种新兴的 API 查询语言，允许前端开发人员以最适合其应用的方式定制 API 查询。所有资源都通过单个 URI 进行访问。得益于这种灵活性和控制性，GraphQL 正变得越来越流行。

SOAP 和 REST 目前已具备成熟有效的访问控制方法，而 GraphQL API 中还没有。

该图表列出了每种 API 或架构风格最常见的攻击和漏洞。

SOAP API

REST API

GraphQL API

XML 外部实体 (XXE) 注入

✓

✓

✓

SQL 注入

✓

✓

✓

命令注入

✓

✓

✓

行为欺骗

✓

SAML 篡改

✓

重放攻击

✓

跨站脚本攻击 (XSS)

✓

✓

身份验证问题

✓

✓

授权问题

✓

✓

拒绝服务 (DoS)

✓

✓

✓

敏感信息泄露

✓

参数篡改

✓

不安全的直接对象引用 (IDOR)

✓

✓

跨站请求伪造 (CRSF) 攻击

✓

中间人攻击 (MITM)

✓

✓

批量处理攻击

✓

此处，我们总结了每种 API 的安全防护最佳实践。

SOAP API

REST API

GraphQL API

访问控制

✓

✓

输入验证

✓

加密

✓

SSL/TLS

✓

单点登录 (SSO)

✓

速率限制

✓

令牌化

✓

实施身份验证

✓

✓

SAML 身份验证

✓

第三方授权

✓

验证 API 参数

✓

查询超时

✓

✓

限制查询深度

✓

限制对资源的访问

✓

使用分页

✓

无论是在云端、本地还是在混合部署中，用于构建 API 的技术栈都会改变您的 API 防护方式。

保护 API 的最常见方法之一是采用多层防御策略，即在每一层应用不同类型的安全防护。这通常被称为“深度防御”方法。

您可以将这些保护措施想象成城堡的围墙。API 发现和 WAF 等边界防御提供最外层的防护。进入城门后，您会在沿途经过不同的关卡。这些关卡能够有效防止在城堡中横向移动，并确保您拥有正确的凭证以访问城堡的不同位置。在现代应用架构中，细粒度的访问控制、API 网关和其他点的额外身份验证就是这些关卡。

下图说明了这些不同的层是如何堆叠起来，从而在流量通过应用架构时逐级保护 API 和应用。每层都包括一些您可为保护 API 而部署的不同技术。

除上述方法以外，这里还有一些其他最佳实践，可跨多个向量实现强大的 API 安全防护。

API 网关接受 API 请求并将其定向到相应的服务。通过部署 API 网关，您可以控制、监控和保护 API 流量。然而，API 网关背后的 API 仍然很容易遭到破坏。为了增强 API 网关的安全防护，可考虑部署 Web 应用防火墙 (WAF) 来拦截攻击及其他恶意流量。

加密是将文本编码为一种密码形式的过程，如果不反向解码，就无法读取原始文本。加密最佳实践是端对端加密 (E2EE)，即对用户和应用之间往返传输的数据全程进行完全加密。数据只能通过解密密钥查看，从而限制非预期用户的访问。

为了进一步限制恶意访问，网站通过由证书颁发机构 (CA) 签名的公共证书和私钥，使用双向 TLS (mTLS) 向客户端表明自身身份。SSL/TLS 私钥用于对访问的完整性进行身份验证、加密和验证。这种双向身份验证能够确保数据的保密性和有效性。当私钥被破坏时，攻击者可冒充有效用户（劫持网络流量并进行篡改），或者在数据流经网络时进行实时录制以便事后离线解密。

关于使用 Let’s Encrypt（一家免费、开放、自动化的证书颁发机构）来签发证书的说明，请参见《为 NGINX 配置免费的 Let’s Encrypt SSL/TLS 证书》。

Oauth 是一个由网站等资源所有者广泛使用的开源标准，允许从获批的第三方授权服务器获得访问令牌的客户端访问其资源。

Oauth 2.0 是最新的行业授权标准。它是一种协议，通过在 HTTP 服务（如 Facebook）上启用 API，允许经过同意的访问，并支持使用不同资源轻松解读用户数据。这些资源在站点之间共享，但不使用用户凭证，而是使用用户名和密码令牌。

Oauth 可通过额外的身份层（称为 OpenID Connect）进行增强。OpenID Connect 基于 Oauth 2.0 框架，并使用身份令牌对其进行扩展。借助身份令牌，OpenID Connect 实现了对用户的身份验证。

您可通过 OAuth 2.0 和 OpenID Connect 的合并授权 (AuthN) 和身份验证 (AuthZ) 方法实现强大的安全防护。

正如 OWASP 十大 API 安全风险中的 API10 所示，监控和日志记录不足会给攻击者带来可乘之机。

监控工具能够显示有关应用性能的有用信息。API 中发生的每项活动都被视作安全防护事件并被记录下来，运维人员可查看日志文件以确定是否有未经授权的活动。

传统的安全模型认为，在既定安全边界内运行的用户、应用、数据和设备是可信的。零信任方法说明，就如今的分布式应用而言——应用组件和基础架构分散在本地、混合和多云环境中，根本没有安全防护边界，因此也就没有可信的“内部人员”之说。它将每个元素都视为潜在的安全防护威胁，并要求就每项操作提供身份验证和授权证明。

NGINX 提供了多款解决方案来保护 API 并确保持续安全防护：