本指南提供了有关保护基于 HTTP 的 API 的建议。它针对的是负责设计或构建提供 HTTP API 的应用程序的技术人员。请注意，您应该针对您的特定设计进行威胁建模，以完全保护基于 HTTP 的 API。

什么是基于 HTTP 的 API？

基于 HTTP 的 API 可实现不同软件系统（通常包括第三方服务）之间的通信，并可用于访问服务和数据库、操作数据，甚至处理用户身份验证和授权。它们是现代互联网应用程序架构中的关键组件。

API（应用程序编程接口）通常定义为一组规范（例如发送到 API 端点的 HTTP 请求的格式）以及响应消息结构的定义，通常为 JSON 格式。API 可用于接收一些数据、上传一些数据或控制操作或系统。 

API 面临的威胁

攻击者可以通过多种方式利用 API 中的弱点和漏洞。例如，他们可以：

• 使用不安全的 API 端点获取敏感数据
• 使用 API 上传恶意代码，并利用它来攻击系统
• 获取 API 访问权限，然后在系统上执行未经授权的操作（例如在银行系统中进行未经授权的付款）
• 使用 API 来操作已存储在系统中的数据 
• 通过反复轮询 API 端点发起拒绝服务攻击 

由于基于 HTTP 的 API 在您的组织外部共享，目的是提供数据或功能，因此您应该执行特定于服务的威胁建模以了解相关的风险和威胁。

1. 安全开发实践

您的 API 被入侵可能会影响运营、损害组织的声誉，甚至可能导致监管机构的罚款。在设计系统之前确定背景非常重要，因为这将确保任何安全控制措施与您面临的威胁相称。例如，用于公共天气预报应用程序的 API 和用于管理生产线的 API 具有完全不同的威胁和风险状况，这将转化为不同的安全控制措施。

威胁模型你的设计

首先对高级设计进行威胁建模，这样您就可以在设计过程的早期了解任何潜在威胁。NCSC 关于威胁建模和OSWAP 十大 API威胁的指导可以为您提供帮助。 

使用有据可查的 API

全面的 API 文档可以为您的 API 设计提供资产管理。这可用于确定：

• 应该作为应用程序的一部分公开的端点 
• 不应暴露的端点（例如开发或管理端点）
• 遗留端点

良好的文档将有助于确保将正确的安全控制应用于需要它的 API 设计部分。尝试使用常用的 API 规范（例如OpenAPI）来记录和描述您的 API。使用社区理解的 API 规范允许使用常用工具来可视化和理解您的 API 设计。

作为本文档的一部分，请确保您有效地管理 API 版本，以确保不会无意中使用已弃用或不安全的版本，并确保客户端始终使用最新的安全版本。通过版本控制，您还可以弃用并最终淘汰不安全或过时的 API 版本，从而鼓励用户迁移到更新、更安全的版本。

安全开发和测试

NCSC 使用“设计安全”一词来描述一种开发方法，该方法鼓励组织将网络安全“融入”产品生命周期的所有阶段，而不是事后才考虑。无论 API 受到多么好的保护，仍然需要安全的开发环境和代码交付。一旦投入生产，任何 API 都应接受适当的安全测试，包括适用于威胁模型的负面测试和模糊测试（而不仅仅是正面测试）。

使用标准

在构建使用基于 HTTP 的 API 的应用程序时，请尝试使用众所周知的适当标准。这可以降低设计中出现安全漏洞的可能性。一些示例包括：

• 使用 JSON 进行数据交换
• 使用 OpenAPI 描述 API 设计
• 使用TLS等标准加密技术来传输数据

您的 API 设计中可以考虑许多其他标准，并且您应该优先使用已尝试和测试的方法，而不是构建自己的方法。

资产登记与治理

资产登记册和有效治理可以帮助组织保持对其 API 的可见性、控制力和保护。资产登记册是一份全面的清单，详细列出了组织基础设施内的所有 API 端点、服务和相关资源。该登记册不仅有助于识别潜在漏洞，而且还能在整个生命周期内高效地监控和管理资产。

有效的治理可确保制定政策、程序和控制措施来保护这些资产，并符合行业标准和监管要求。 

2. API 认证与授权

实施强大的身份验证和授权对于保护 API 至关重要，可确保只有合法用户或服务才能访问端点并执行操作。身份验证可验证发出 API 请求的实体的身份，而授权可控制经过身份验证的实体可以执行哪些操作。

在许多情况下，身份验证和授权是紧密联系的，某些机制同时发挥这两种功能。例如，身份提供者颁发的令牌可以对用户进行身份验证，并包含定义用户有权执行哪些操作的声明。

选择正确的身份验证和授权方法需要仔细规划并考虑应用程序的特定需求。

用户访问

应用程序通常需要代表用户与 API 进行交互，但传统的用户身份验证方法并不适合此目的。与使用用户凭据相比，更安全的方法是通过身份提供商进行用户身份验证。此过程会生成临时凭据（例如令牌或 Cookie），然后应用程序可以使用这些凭据安全地与 API 进行交互。

有关更多信息，请参阅 NCSC 关于为企业在线服务选择身份验证方法和多因素身份验证的指南

API 身份验证

安全 API 身份验证的良好实践包括以下内容：

安全的生成和交换

凭证应在安全的环境中生成，最好不要从生成凭证的地方导出。对于基于公钥加密的凭证尤其如此。如果需要导出凭证（通常使用对称密钥时），则必须使用安全传输来完成，并且该过程应自动化，几乎不需要人工参与。 

避免将凭证直接硬编码到存储在版本控制中的源代码中，尤其是当存储库可公开访问或广泛共享时。一旦进入版本控制，机密可能很难完全删除。攻击者经常扫描公共存储库以查找此类凭证。

安全凭证存储

确保您的 API 凭据已安全存储。考虑使用机密管理器（具有安全存储后端，如 HSM 或云 KMS），或将凭据存储在防篡改硬件支持的存储位置（例如 USB 令牌或 TPM）。安全性较差的机密会增加攻击者窃取您的凭据的可能性，尤其是当您将机密存储在多个位置时，这会使审计变得困难（此问题称为“机密蔓延”）。

对于短期凭证（或用于对低价值应用程序进行身份验证），您可以使用软件支持的存储。您应该平衡凭证的有效时间长度、价值和使用的存储方法。

凭证有效期

凭证的有效期应设置为适合用例和威胁的适当时间。凭证到期后应自动轮换或续订，轮换过程应自动化，无需人工参与。如果凭证无法存储在安全的存储方法中，或者凭证不具有抗重放性，则应通过缩短凭证的有效期来降低风险。 

避免使用长期访问密钥，因为如果密钥被盗用，可能会授予无限期访问权限，从而可能暴露数据和服务。获得这些密钥访问权限的攻击者可以滥用您的 API 资源，直到密钥被轮换或撤销。使用短期密钥将缩短攻击者在密钥变为非活动状态（对攻击者毫无用处）之前可以使用密钥的时间窗口。

防重放凭证

使用具有防重放保护的凭证。这可以通过使用基于公钥加密的凭证来实现，例如证书或签名的 JSON Web 令牌 (JWT)。凭证的使用应成为任何监控策略的一部分，任何滥用行为都应发出警报。

避免使用弱身份验证方法

不要使用弱身份验证方法，例如基本身份验证或 API 密钥。基本身份验证以 Base64 编码格式在每个请求中传输用户名和密码，而 API 密钥则放置在 http 标头中并作为共享承载令牌。这两种方法都很容易受到攻击，通常是由于机密管理不善。它们还经常提供广泛的访问权限，且不会过期或限制权限。您应该采用更强大的身份验证方法（例如签名的 JWT 或证书），这些方法应按照 NCSC 指导实施和管理。 

API 授权

一旦用户通过身份验证，控制他们可以执行哪些操作以及他们可以在 API 中访问哪些数据就很重要了。授权根据请求实体的身份和权限来控制对资源的访问。除非您托管完全开放的公共 API，否则实施授权框架至关重要。

指导有效授权治理的三个基本原则：

1. 强制执行最小权限：授予用户或进程执行其任务所需的最低限度的访问权限，从而限制潜在的安全漏洞或恶意活动。
2. 默认拒绝：默认限制访问，只允许明确授权的实体进入。
3. 验证每个请求的权限：持续验证系统内每个操作的访问权限。

授予令牌过多权限会增加数据泄露或服务滥用的风险。这通常是由于使用通用密钥或范围过广的令牌，并拥有对各个端点的完全访问权限所致。 

OpenID Connect 和 OAuth2.0

OAuth 2.0 和 OpenID Connect (OIDC) 是两个互补的行业标准框架，用于保护 API 访问和用户身份管理。您可以使用一系列标准来实现我们的身份验证和授权指南。

1. OAuth 2.0 是一个授权框架，允许第三方应用程序代表用户访问资源，而无需暴露其凭据。它使用令牌促进安全的委托访问，但本身并不提供身份验证。 
2. OpenID Connect 通过引入身份层扩展了 OAuth 2.0，该身份层使应用程序能够通过 JWT 验证用户身份并检索与身份相关的声明。它通过合并 ID 令牌来实现这一点，该令牌包含有关经过验证的用户的已验证信息。此扩展有助于实现单点登录 (SSO)，使用户能够安全地访问多个应用程序，而无需重新输入凭据。

OAuth 的最新进展引入了改进的凭证保护安全机制，例如证书绑定令牌和所有权证明 (DPoP)。尽管这些安全增强功能相对较新，但它们得到了广泛支持，并被强烈推荐作为OAuth 2.0 最佳当前实践 (BCP)指南的一部分，以减轻令牌盗窃和重放攻击等风险。

3. 传输中的数据保护

API 数据应使用 TLS（传输层安全性）在传输过程中受到保护。请参阅NCSC 关于推荐配置文件的指导，以安全地配置 TLS。使用过时的 TLS 协议或弱密码套件的 API 会使传输中的数据暴露给攻击者，从而可能被拦截和解密。这使得 API 容易受到中间人 (AiTM) 攻击，从而可能泄露凭据和个人数据等敏感信息。

如果 API 是为小型社区托管的（或者是私有 API），请考虑使用相互认证协议，例如Mutual TLS (mTLS)。这将提供双向身份验证，确保客户端和服务器在建立安全连接之前验证彼此的身份。如果您确实使用 mTLS，则可能需要为 mTLS 的客户端身份验证部分 构建私有 PKI 。

4. 输入验证

1. 句法和语义验证

输入验证是在处理 API 收到的数据之前对其进行检查和验证的过程。此验证可确保输入符合指定的标准（例如数据类型、格式、长度和范围），并且不含潜在的恶意或意外内容。有关更多信息，请参阅NCSC 安全设计原则中的“使入侵变得困难”部分。

有效的输入验证对于防止各种安全漏洞至关重要，包括注入攻击、数据篡改和拒绝服务 (DoS) 攻击，这些攻击可能危及 API 资源的机密性、完整性和可用性。 

您应该尽早验证输入，最好是在从外部源接收数据时进行验证，并确保在每个系统层都进行验证。层与层之间无意的不一致是造成漏洞的一个众所周知的原因。在用户界面层，它有助于尽早发现基本错误。应用程序逻辑层强制执行业务规则，确保只有有效数据才能继续，而数据访问层则防止注入攻击并强制执行数据库约束。在所有层上进行一致的验证可降低风险并创建更安全的纵深防御架构。  

如果使用 API 网关，它应该执行初始验证，但不应是唯一的验证点。实施多层方法，其中网关处理基本检查，而后端服务执行详细的、特定于上下文的验证。为了简化此过程并确保一致性，请考虑实施中央输入验证库或流程，这样您就无需为每个功能重新实现验证逻辑。

句法和语义验证

输入验证应在句法和语义层面进行：

• 语法验证可确保输入数据的语法和结构正确，通常侧重于预定义的模式、格式和约束。验证检查输入是否符合预期的标准和模式，例如电子邮件地址、电话号码、日期或货币符号的正确格式。
• 语义验证验证相关业务环境中数据的正确性（例如确认开始日期早于结束日期，或在预期范围内）。

通过强制执行语法和语义验证，开发人员可以拒绝任何不符合指定语法规则且在预期上下文中准确的输入，从而降低处理错误、数据损坏、安全漏洞的风险并提高数据准确性。

语法验证的良好实践

JSON 解析器

严格的 JSON 解析器可确保数据在语法上正确，验证其是否符合正确的 JSON 格式。如果输入数据包含结构错误（例如括号不正确或逗号放错位置），解析器将引发错误或异常。

集中验证库

使用经过充分测试的输入验证库或框架。这些库通常提供类型检查、范围验证和清理等功能，减少对复杂且难以维护的正则表达式模式的依赖。

允许列表

允许列表验证明确定义授权输入并确保仅接受允许的值。例如，对于来自固定选项（如下拉列表）的结构化数据，应采用数据格式的精确匹配。

语义验证的良好实践

架构验证

JSON 模式可用于定义通过 API 交换的数据结构，并根据这些模式验证传入的有效负载。还应使用模式验证来确保攻击者不会发送意料之外的额外子句（键值对）。 

数据类型验证器

许多编程语言都提供内置的类型检查机制。例如，在 Java 或 TypeScript 等静态类型语言中，编译器可以强制确保数据类型的正确性。在 Python 或 JavaScript 等动态类型语言中，可以使用库或自定义函数来执行类型检查。

最小值和最大值范围

确保数值参数和日期在指定的最小和最大范围内，并且字符串符合定义的长度标准。

转义和编码

对用户输入进行转义和编码是一项重要的安全措施，通过将用户输入转换为在应用程序中不具有任何功能意义的格式，确保正确处理特殊字符以防止漏洞（例如 SQL 注入或跨站点脚本）。

5. 缓解 DoS 攻击

针对 API 的常见攻击是耗尽 API 可用的资源，这可能导致 DoS 或增加托管 API 的成本。考虑限制或限制 API 的使用速率。“限制”是指对 API 的调用频率/速度施加配额。这通常以每秒可以发出的请求数来衡量，并且应该允许合法消费者使用量激增。当 API 缺乏速率限制和限制时，它们很容易受到过多请求的影响，从而导致服务器不堪重负，导致拒绝服务 (DoS) 攻击或资源耗尽。

允许使用量激增是一种很好的做法，因为有时 API 的使用者可能需要发出更多合法请求。您还应该记录使用者尝试访问 API 的次数，以便分析是否存在合法的流量激增，或者您是否受到了潜在的 DoS 攻击。有关如何理解和缓解 DoS 攻击的更多信息，请参阅 NCSC 的拒绝服务 (DoS) 指南。  

6. 日志记录和监控

在此页面上

1. 日志记录
2. 监控

日志记录和监控虽然密切相关且经常一起使用，但用途不同。日志记录是回顾性的，提供全面的审计跟踪，可用于故障排除、取证分析、合规性审计和事件响应。它侧重于存储信息以供日后审查和分析。另一方面，监控涉及对系统行为、性能指标和安全指标的持续、实时观察和分析。

允许使用量激增是一种很好的做法，因为有时 API 的使用者可能需要发出更多合法请求。您还应该记录使用者尝试访问 API 的次数，以便分析是否存在合法的流量激增，或者您是否受到了潜在的 DoS 攻击。有关如何理解和缓解 DoS 攻击的更多信息，请参阅 NCSC 的为了安全目的需要收集哪些数据以及何时收集。  

日志记录

日志记录是对系统内事件、操作和交易的系统记录。这些日志按时间顺序记录用户活动、系统更改和数据访问，从而全面了解 API 的运营状况。在 API 安全中，日志记录是保持对 API 生态系统内操作和交互的可见性的重要组成部分。

记录安全事件

确保日志捕获重要的安全相关事件，包括身份验证和授权活动，例如登录尝试、权限更改、失败的请求、错误和敏感操作，例如密码更改、帐户修改和权限提升。

实施集中日志记录

如果可能的话，实施一个集中式日志系统来汇总和分析日志，确保来自多个服务和微服务的数据集中在一个地方。

记录访问、错误和事务日志

跟踪访问日志、错误日志和交易数据以监控 API 活动并确保安全。记录每个 API 调用的详细信息，包括时间戳、源 IP、用户身份和访问的端点。这有助于识别未经授权的访问、跟踪用户交互并检测可能表明潜在安全威胁或欺诈活动的异常交易模式。

保护日志中的敏感数据

绝不应记录密码、API 密钥、访问令牌和个人身份信息 (PII) 等敏感数据。相反，应使用数据编辑或屏蔽来保护机密信息，并确保日志在静止和传输过程中均经过加密。

监控

监控系统跟踪关键指标，例如 API 响应时间、正常运行时间、资源利用率和安全事件。它们检测异常、生成警报，并在超出预定义阈值或发现可疑活动时通知管理员或安全团队。

监控是一种主动预防性措施，旨在发现并解决发生的问题，确保 API 基础设施持续健康安全。监控在维护 API 的完整性和可用性以及检测和缓解安全威胁方面发挥着至关重要的作用。

启用实时监控和警报

使用 SIEM（安全信息和事件管理）工具来监控日志、检测威胁并启用异常检测。设置可疑活动警报，例如多次登录尝试失败（表示潜在的暴力攻击）或 API 流量激增（可能表示 DoS 攻击）、日志突然停止（可能表示篡改或正在进行攻击）或异常/大量数据传输（可能表示数据泄露）。确保持续的日志完整性和监控数据移动有助于在安全威胁升级之前检测和缓解它们。

端点性能跟踪

实施端点性能跟踪，重点监控 API 端点的可用性和性能。它跟踪响应时间、错误率和可用性，以确保它们按预期运行，并检测可能影响 API 可用性或可靠性的任何问题。

7. 限制暴露面

不应过度暴露 API 端点或允许已知的恶意 IP 地址连接到API。限制暴露面，使攻击者甚至无法访问 API 的某些敏感部分，这将降低您的应用程序受到攻击的可能性。 

限制接触端点

API 端点是客户端用来连接到 API 的 URL。应该有效管理向客户公开的 API 端点。除非访问权限严格限制在受信任的网络（或攻击者无法控制的设备）内，否则攻击者可能会拥有一定程度的访问权限（可能通过反编译应用等方法来提取 API 端点和密钥）。

删除未使用的端点

当 API 更新时，端点有时会暴露在外，尤其是在 API 正在（或已经）停用的情况下。在这种情况下，这可能意味着所有监控和安全功能都将处于非活动状态，尤其是在不再使用的情况下。这也可能意味着可能存在漏洞的 API 端点暴露在外且可访问。当 API 端点被弃用时，IT 团队需要确保端点不再可访问并且访问被阻止。第 1 节中提到的资产登记册将对此有所帮助。  

限制对特权端点的访问

被视为敏感的端点（例如用于管理 API 的端点）也应具有受限的网络访问权限，并且不应公开访问。这使得攻击者或恶意用户更难访问敏感 API 并试图利用它。您应该主动扫描您的环境，以确保您知道哪些内容是公开的。这将使您能够主动发现任何过度暴露的旧版、开发或管理 API。

阻止已知恶意 IP 地址 

阻止已知的恶意 IP 地址以及不应连接到您的 API 的 IP 地址类别的连接。以这种方式阻止 IP 地址通常是许多 Web 应用程序防火墙 (WAF) 中提供的功能。如果可能，您应该尝试使用托管规则集来阻止 IP 地址，因为这将大大减少您的管理开销。您需要调整规则集，因此您可能需要在执行规则之前监视规则，以防您最终意外阻止了合法流量。

封闭社区的 API 暴露

如果您托管的是私有 API 或在封闭社区（例如 CNI 部门或政府部门组）中使用的 API，请考虑进一步限制 API 的暴露。这可以采用 mTLS、IP 地址允许列表或使用 VPN 的形式。您将使用哪种方法来减少暴露将取决于封闭社区的规模、威胁和要求。 

API 响应

如果 API 返回过多或不必要的数据，则可能会泄露敏感信息，例如内部标识符、用户个人标识符 (PII) 或调试详细信息。此类暴露可能有助于攻击者收集针对性攻击的情报，或导致无意中泄露用户隐私。

API 网关安全

大规模部署 API 时，请使用 API 网关，因为这将提供一致的安全方法。如果您在公共云中托管 API，那么您应该考虑使用云原生基础设施，而不是将本地解决方案迁移到云中。 

API 网关充当客户端和后端服务之间的中介，为管理和保护 API 流量提供集中入口点。API 网关的集中特性简化了大规模构建 API 时安全功能的实现。API 网关可以提供一种方法来提供安全功能的一致实现，因为这些功能是在网关中提供的，而不是后端应用程序代码中提供的。

您可以在 API 网关中找到的一些安全功能包括：

• 架构验证（如第 4 节所述）
• 客户端的身份验证和授权；API 网关通常支持 OpenID Connect 和 OAuth 2.0 等框架
• 提供一个用于监控和记录 API 端点的中心点
• 集成到 WAF 和 IDS 等工具中，可以用作纵深防御并限制 API 的暴露