API 安全最佳实践：开发者检查清单

TL博士

大多数 API 安全漏洞都源于授权机制的缺陷，而不是特殊的漏洞利用。 OWASP API 安全十大风险类别中，前五大类别中有三项是授权失败，其中最主要的是…… BOLA.

你无法确保你不知道存在的东西的安全。 库存管理不当 它拥有自己专属的OWASP风险类别，也是其他所有控制措施所依赖的基础。

在部署前发现风险，而不是部署后。对代码和 API 规范的静态分析发现一个损坏的端点。 pull request只需一个 commit运行时测试发现同样的问题，代价是发生一次安全事件。

这是一份需要持续运行的检查清单。在每个 pull request并非预发布评测： 10个练习从库存和授权到速率限制、响应数据泄露和第三方信任。

您的 API 攻击面会随着每 pull request大多数团队只有在端点上线并开始接收流量后才会发现它暴露在外，这意味着修复工作原本需要花费大量资金。 commit 现在，审查工作需要提交一份事件报告。本指南将详细介绍在生产环境中真正有效的 API 安全最佳实践，并以清单的形式呈现，您可以立即将其应用于自己的代码库，而不是列出一些无人实践的抽象原则。

为什么 API 安全最佳实践现在看起来有所不同

API 曾经是连接各个系统的纽带。如今，它们几乎成了所有事物的主要接口：移动应用、合作伙伴集成、人工智能代理、内部微服务等等。这种转变改变了 API 保护最佳实践的涵盖范围。仅仅保护你已记录的 API 已经远远不够；你还必须考虑到团队构建但忘记记录的那些 API。

两个数字可以解释为什么这件事很重要。 OWASP API 安全 Top 10 该机构将授权问题列入五大风险类别中的三项，这意味着大多数实际的 API 安全事件都源于少数可预防的模式，而非罕见的零日漏洞。此外，不当的库存管理也被列为一项独立的风险类别：团队可能因为不知晓仍在运行的 API 而遭受攻击。

以下每一条都贯穿着同一个主题。良好的 API 管理最佳实践始于了解你拥有什么，而不仅仅是捍卫你记得记录的内容。

API 安全最佳实践概览

在详细清单之前，先来看简短版本：要实施什么，它实际能防止什么，以及紧迫程度。

练习	它能防止什么	优先
HTTPS/TLS 加密	数据拦截、中间人攻击	其他要求
身份验证（OAuth 2.0、JWT）	未经授权的访问、身份欺骗	其他要求
授权和访问控制	权限提升、数据泄露	其他要求
输入验证	注入攻击、格式错误的请求	其他要求
完整的 API 清单	未记录且已弃用的端点仍然暴露在外	其他要求
速率限制	暴力攻击、DDoS攻击、滥用	高
API 密钥管理	凭证盗窃，未经授权的使用	高
记录和监控	未被发现的入侵事件，缓慢的事件响应	高
部署前的静态分析	在任何人审核之前，曝光就已经交付生产环境了。	高
安全测试（SAST + DAST)	未知漏洞、回归	高

将“必需”行视为任何 API（无论是内部 API 还是面向公众的 API）的不可协商的基准。“高优先级”项则区分了能够及时发现问题的程序。 pull request 从事故报告中得知。

API 安全最佳实践清单

1. 在构建防御体系之前，先建立完整的库存清单。

你无法保护一个你都不知道存在的端点。所有 API 保护最佳实践都应从一份完整的清单开始：清单应包含每个端点、其方法、路径、所属服务和模块，以及是否需要身份验证。这些信息应同时从源代码和 API 规范（OpenAPI、Swagger）中提取，而不仅仅依赖于文档，因为被遗忘和孤立的端点恰恰隐藏在两者之间的空白处。

Xygeni 的定位： Xygeni API 安全性 它直接从您的应用程序源代码和 API 规范构建此清单，在任何端点进入生产环境之前，将您的团队记录的端点和无人记录的端点呈现出来。

2. 在对象和函数级别强制执行授权

对象级和函数级授权缺陷始终位列 OWASP API 安全十大问题之首。最佳实践并非“添加身份验证”，而是在每个请求中检查是否存在身份验证问题。 这位特定用户 允许访问 这个特定对象不仅仅是确认用户是否已登录。身份验证用于确定用户的身份。授权用于确定用户可以访问哪些内容，并且每次都需要进行检查，而不能仅凭有效的令牌来推断。

3. 验证并清理 API 接收的所有内容

所有参数、标头和正文字段在未经证实之前都被视为不可信输入。务必执行严格的模式验证，拒绝非预期字段（这是防止批量赋值的有效手段），并且永远不要依赖客户提供的数据来确定访问范围或定价逻辑。

4. 从设计之初就考虑速率限制和节流，而不是事后补救

不受限制的资源消耗会导致单个客户端耗尽您的基础设施资源，或导致按需付费的后端服务成本飙升。请为每个端点、每个用户和每个 API 密钥设置限制，并确保限制值能够根据实际操作成本进行调整，而不是采用统一的固定值。

5. 将每一次回复都视为潜在的数据泄露

当 API 返回的数据超过客户端所需，并依赖前端进行过滤时，就会发生数据过度泄露。这是一种习惯，而非罕见的错误，也是最常见的 API 安全最佳实践违规行为之一，因为只有当有人检查原始响应而非渲染后的 UI 时，才会发现问题。

Xygeni 的定位： Xygeni API 安全功能直接在 API 响应中标记 PII 泄露，在数据发布之前就发现过度共享，而不是在客户或监管机构注意到之后才发现。

6. 维护一份准确、最新的 API 清单，包括已弃用的 API。

不当库存 API 管理之所以在 OWASP 列表中单独列为一个类别，是有原因的：已弃用的 API 版本和未记录的测试环境通常仍然可以访问，而且即使很久以后人们才想起它们的存在，它们仍然可能存在漏洞。API 管理最佳实践方案必须包含停用流程，而不仅仅是发现问题。

7. 仔细审查你的 API 对第三方的信任程度

不安全地使用第三方 API 的风险被低估了。开发者往往更信任来自其他 API 的数据，而不是用户输入，这恰恰本末倒置；第三方集成仍然是外部的、未经验证的来源，应该以同样的方式进行验证。

8. 向开发人员提供证据，而不仅仅是警报。

如果发现“此端点授权存在问题”，则需要有人先进行调查才能着手修复。而如果发现问题能够精确指出是哪个文件、类、方法还是行，开发人员就可以立即采取行动。这不仅是 API 的安全最佳实践，也是整个安全流程的最佳实践：需要先进行调查才能修复的问题会拖慢整个流程。

Xygeni 的定位： Xygeni API 的每一个安全漏洞都会指出具体的处理程序、文件、类、方法以及引入该漏洞的行号，因此修复工作会在发现漏洞的那一刻立即开始。

9. 在部署前而非部署后发现风险。

运行时 API 测试表明，当 API 开始处理流量时，某个端点就已经暴露出来了。而对代码和 API 规范的静态分析则发现，即使 API 尚未加载，也存在同样的暴露风险。 pull request当修复成本为一美元时 commit 而不是事件响应。最有效的 API 管理最佳实践将静态发现作为第一层，运行时测试作为第二层补充检查，用于验证已上线的功能。

Xygeni 的定位： Xygeni API 安全性采用静态设计，在发布前分析代码和规范，并与……协同工作。 Xygeni DAST 用于对已投入生产环境的应用程序进行运行时覆盖。

10. 将 API 风险与应用程序的其他风险放在同一层级。

API故障并非孤立发生。API漏洞通常存在于依赖项问题或配置错误等下游问题中。 pipeline或者，也可能是泄露的机密信息。将 API 安全视为一个独立的工具，并为其配备单独的控制台，意味着在最关键的时刻会丢失上下文信息。

Xygeni 的定位： API 安全性与 SAST, SCA，秘密， IaC而且，DAST 和 API 检测结果都集成在同一个 Xygeni 平台上，因此 API 检测结果会直接显示在导致该结果的代码和依赖项风险旁边，而不是单独显示。 login.

将清单变成一种习惯

API 安全最佳实践只有作为持续性实践才能发挥作用，而不是发布前的审查。对每个 API 运行清单和静态分析。 pull request而不是每季度一次。对待新的、未记录的端点，要像对待新的、未记录的依赖项一样：立即进行调查，而不是拖延。衡量 API 保护最佳实践的方式，要与衡量其他任何部分的方式相同。 SDLC关键在于你发现问题的速度，而不仅仅是你是否发现了问题。

快速解答：API 安全最佳实践问答

问题	回答
最重要的 API 安全最佳实践是什么？	对每个端点都强制执行强大的身份验证和授权，而不仅仅是您记得保护的端点。
内部 API 是否应该使用 HTTPS？	是的。对所有 API 流量进行加密，包括服务间的通信，而不仅仅是面向公众的端点。
API密钥足以保障安全吗？	不。API密钥识别的是应用程序，而不是用户。要进行真正的身份验证，需要将其与OAuth 2.0或JWT结合使用。
BOLA是什么？	对象级授权失败：API 未能验证用户是否有权访问特定资源。自 2019 年以来，它一直位列 OWASP API 安全十大漏洞榜首。
API密钥应该多久轮换一次？	定期检查，每 60 至 90 天一次，以及在任何疑似安全漏洞出现后立即检查。
限速返回的状态码应该是什么？	429 请求过多，带有 Retry-After 标头，告诉客户端何时重试。
即使经过网关，我也需要在服务器上验证输入吗？	始终如此。无论上游客户端或网关已经检查过什么，都必须在 API 层进行验证。
如何测试 API 安全性？ CI/CD?	检查每个系统的身份验证、授权、输入验证和速率限制。 pull request不仅要在发布前进行审核，而且要实现自动化审核，而不是依赖人工审核。