大多数 API 泄露并不是黑客攻击你，而是直接进入

Source: Dev.to

常见误解

大多数开发者把 API 泄露想象成戏剧性的事件：加密被破解、密钥被窃取、暴力破解攻击。人们安慰自己的信念是，只要身份验证能工作，API 就是安全的。

API 泄露的真实情况

实际上，大多数 API 事件都涉及 有效的令牌、正确的请求头以及预期的流程。攻击者并不是在与系统对抗，而是与系统合作。

API 中的信任层

API 建立在多个信任层之上：

1. 身份提供者 – 你信任进行用户认证的来源。
2. 令牌 – 你信任客户端提供的令牌。
3. 用户行为 – 你假设已授权的用户会表现得合理。

最后一个假设是问题的根源。API 评估的是规则，而不是意图。如果请求符合已定义的规则，就会通过，无论请求数据的原因、频率或访问模式是否合理。这些考量是人的假设，必须显式强制执行。

典型事后分析发现

泄露分析往往显得“乏味”：

• 用户访问了他们被允许查看的数据。
• 没有触发速率限制。
• 没有出现身份验证失败。
• 其他一切都如预期工作。

错误并不是缺少 HTTPS 或 OAuth；而是把“身份验证等于安全”当成了信条。身份验证只能回答 谁，却对 是否应该、范围、频率、影响 毫无说明。

设计失误与宽容系统

资深工程师了解到，安全失效常常是设计失误的结果。系统往往 默认宽容，而 仅在理论上限制。如果你的 API 更信任令牌而不是理解行为，它并不安全——它只是礼貌。礼貌在大规模时代价高昂。

结论

安全不仅仅是阻止外部攻击者，更是为受信任实体的行为定义并强制正确的期望。构建稳健的 API 需要超越仅靠身份验证的思维，转向主动监控意图、频率和影响的设计。