构建 2026 年安全 API：开发者不可忽视的威胁

如今，每个产品团队都会先发布 API，再发布 UI。移动应用、合作伙伴集成、内部微服务，以及接入系统的 AI 代理都通过同一组端点进行通信。这种流量的集中使得 API 层成为堆栈中最具吸引力的单一目标，而攻击者也深知这一点。Verizon 2025 年数据泄露调查报告将 Web 应用和 API 攻击列为已确认泄露的主要攻击向量之一，并且流量正从浏览器会话转向机器对机器调用，而大多数安全团队对这类调用的监控仍不如对用户登录的监控严密。

破损的对象级授权仍会破坏大多数 API

OWASP 在其 2023 年 API 安全 Top 10 中将破损的对象级授权列为 API1，且它至今仍是导致真实事件最多的 API 缺陷。该模式简单且团队仍在不断发布：像 /api/orders/12345 这样的端点能正确验证调用者身份，却从不检查该调用者是否真正拥有订单 12345。更换 ID 即可读取或修改他人的数据。

请在对象级别而非端点级别修复此问题。每个通过 ID 触及资源的处理程序，都需要在返回数据前进行显式的所有权或权限检查，而不仅仅是在入口处验证会话令牌的有效性。将此检查集中到共享的授权库或策略引擎中，以确保单个开发者不会在截止期限压力下遗漏。像运行功能测试一样，对 API 测试套件运行自动化授权模糊测试。Postman 的 API 状态报告已连续多年指出，授权测试是 API 开发工作流中最常被跳过的步骤之一，而 BOLA 仍频频出现在漏洞赏金报告中，因为团队仍将身份验证和授权视为同一问题。

面向 LLM 的 API 带来新的威胁类别

包装或前端语言模型的 API 带有标准 REST API 所没有的风险。OWASP LLM 应用 Top 10 将提示注入、过度代理和不安全的输出处理列为主要风险，而这三者都直接通过 API 层暴露，而不仅仅是通过聊天小部件。

将用户或上游系统可影响的每个字段都视为对模型的不可信输入，并将每个模型输出视为对下游系统的不可信输入。不要让模型响应在未经中间验证的情况下触发数据库写入、文件操作或对另一个内部 API 的调用。如果通过 API 暴露函数调用或工具使用，请将每个工具的范围严格限定，并要求显式白名单，而不是授予模型对内部端点的广泛访问权限。应按令牌成本和调用可触发的下游操作开销来限流，而不仅仅是按请求次数，因为单个提示可能分散成数十个内部调用。当 AI 代理自主调用 API 时，应为每个代理颁发其自己的短期、范围狭窄的凭证，而不是共享服务账号。共享凭证会将一个被攻破的代理转化为对使用该凭证的所有代理的完全访问权限。

网关处的零信任执行

基于边界的安全假设存在一个可信的内部网络，而一旦服务跨越多个云、第三方集成以及 AI 代理按非完全可控的计划进行调用，这一假设便会失效。零信任将每个请求视为不可信，直到它证明自己，API 网关就是一致执行该策略的地方，而非依赖每个服务独立完成。

在服务之间实施双向 TLS，使双方都能对连接进行身份验证，而非仅由调用者对服务器进行身份验证。颁发具有狭窄作用域的短期 OAuth 2.0 令牌，而非授予数月广泛访问权限的长期 API 密钥。将作用域定义为特定操作（orders:read、orders:write），而非广泛的资源级访问，从而使受损令牌的爆炸半径受限。在网关处按客户端身份而非 IP 地址执行速率限制和配额策略，因为基于 IP 的限制在面对分布式流量和共享基础设施的合法多租户客户端时会失效。Gartner 预测，随着组织认识到 API 流量现已超过大多数企业环境中的传统 Web 流量，对 API 安全工具和 API 网关的支出将继续增长，而网关级策略执行是在不重写每个服务的情况下应用零信任的实际方法。

密钥管理和凭证卫生

源代码仓库中硬编码的 API 密钥和数据库凭证仍是 API 泄露最常见且最可预防的原因之一。GitHub 的密钥扫描程序已在公共仓库中标记了数百万暴露的凭证，其中相当一部分属于开发者本打算在推送前删除的生产 API 密钥。

将密钥存储在专用保险库（HashiCorp Vault、AWS Secrets Manager 或云提供商的等效服务）中，并在运行时将其拉入应用程序，而非将其烘焙到签入版本控制的配置文件或环境变量中。按固定计划轮换 API 密钥和签名密钥，并在团队成员离职或事件暗示可能暴露时立即轮换。只要架构允许，优先使用短期签名令牌而非长期静态密钥，因为泄露的令牌在几分钟内过期造成的损害远小于无限期有效的密钥。在 CI 管道中添加自动化密钥扫描，使提交的凭证在合并前即被阻止，而不是等到生产环境才被发现。

这对工程团队意味着什么

这些威胁在概念上并不新鲜。变化的是攻击面。产品所依赖的每个内部微服务、每个合作伙伴集成和每个 AI 代理，都增加了攻击者可探测的另一组端点，而攻击者用于发现破损授权和泄露凭证的工具，其速度已快于大多数团队的补丁周期。将 API 安全视为从编写第一个端点开始的设计约束，而非发布前的检查清单，并养成像测试功能一样测试授权和密钥卫生的习惯。

希望以结构化方式在整个工程组织中建立这些习惯、而不是依赖单个开发者临时学习的团队，应考虑专门的 IT 安全培训。