API 安全九大威胁与防御

API 让外界能访问大量（可能敏感的）数据，却又绕过了浏览器的防护。光盯着 SQL 注入和 XSS 不够——你更该担心坏分子把客户记录整库翻一遍。Captcha、浏览器指纹这类传统手段对 API 基本失效，因为 API 本就要处理海量程序化调用。第一步是把自己摆到黑客位置，再给 API 装上检测并拦截常见攻击、以及未知零日的能力。下面 9 条里，部分在 OWASP API 安全榜上，部分不在。

多数 API 暴露的是实体列表（如 /users）。黑客可写脚本，以一个随机延迟循环翻页，把整库数据刮走——尤其当实体意外暴露了 PII 或可泄露业务数据时，危害极大（Venmo 即前车之鉴）。简单限制 take 数量既伤合法大客户同步，又挡不住带随机延时的脚本。正确做法：按用户或 API key 跟踪单位时间内访问的单一资源总量，触阈（如「1 小时内触碰 100 万条」）即封禁，像 Captcha 一样拖慢黑客扩张速度。

API 多由 API Key 或 JWT 保护，安全工具能据此检测异常、自动封禁。但黑客会像 Web 黑客用大量 IP 池绕过 DDoS 防护那样，批量生成大量 key。最易的防御是要求真人注册才能生成 key，用 Captcha 与 2FA 挡住机器人；除非有正当理由，新用户不应能程序化生成 key，异常检测也要做在「用户/账户」层级而非单个 key 上。

API 常因使用方式放大泄露概率：长期有效的 key 被存进环境变量后遗忘；调试时开发者把带 key 的 CURL 粘到 GitHub Issues/Stack Overflow；key 多为不记名令牌、无二次验证。若因用户失误泄露，责任不全在用户——提供方也应降低风险面。最易的缓解是双令牌：环境里只存长寿命的刷新令牌，用它换短效访问令牌；SDK 初始化时自动换发，即使 CURL 被贴出去，攻击窗口也只有数小时。

API 开启了「客户程序化访问」的新模式，也让 DDoS 防护变难：传统防护靠指纹识别机器人流量，但 API 流量本就像机器人、又无浏览器 Cookie。妙处在于几乎每次访问都要带 key——无 key 的请求可直接拒绝（且要在 JSON 解析等后续中间件之前尽早短路）；已认证的请求则用按 key 的限流计数器，超阈返回 429，算法可选漏桶或固定窗口。

API 和 Web 服务器一样讲卫生。SSL 配置错或放行非 HTTPS 都会漏数据；现代应用几乎没理由接受非 HTTPS 请求，但客户可能误发，而 API 没有浏览器那层 HSTS/重定向保护。应用去 Qualys SSL Test 测实现，在负载均衡上拦掉所有非 HTTP 请求，清掉会泄露实现细节的响应头与错误信息。

API 暴露的是按 key 隔离的动态数据，任何缓存都要能按 key 作用域隔离，避免串味。即便你自己不缓存，也可能把客户坑了——若客户用代理、且同时持有多个 key（开发/生产），会看到交叉污染的数据（Twitter 计费信息泄露即此因）。大坑：很多 API 不用标准 Authorization 头，而用 X-Api-Key 之类自定义头，缓存服务器不知这是认证请求，便直接缓存了。正确做法：设 Cache-Control: no-store, no-cache, must-revalidate 与 Pragma: no-cache。

日志监控不足是 OWASP API 安全 Top 10 之一。多数泄密研究显示，发现数据泄露平均要 200 多天；没有日志监控，攻击者可一直利用同一漏洞甚至继续挖。正确做法：日志不仅要记请求本身，还要关联回用户做行为分析，并留存至少一年；系统要受保护，防止数据被误删或过早退役。GDPR/CCPA 对安全用途的审计日志有例外。

同一 API 服务可能同时被内外使用。端点没写在文档里，不代表黑客调不到。除鉴权/授权外，还应确保这些端点根本不暴露到公网——在负载均衡或 API 网关上做，多层防护是通用预防策略。

多数开发者会加全局鉴权（API Key/OAuth）确认「你是谁」，但更难也更易忘的是授权——确认这个已识别的人能否访问特定资源，可用 API 作用域、租户 ID、用户 ID 等做。它绑定你的应用逻辑、不总是横切，常被忽略。除非对象标识符熵足够高，否则黑客可轻易遍历 ID（SQL 自增 ID 尤甚）。修复：确保已认证用户被授权访问生成响应所需的全部资源，可对照用户 ID 或 ACL 校验。

9 大威胁里，④DDoS、⑦日志不足、⑨越权恰好是 YesApi Pro 网关的强项：统一鉴权 + 细粒度授权（对象级 ACL）+ 按 key 限流（超阈 429）+ 调用日志留存与审计，相当于在后端之前就筑起护城河；私有部署 + 源码交付还能对照 OWASP 逐条加固。把安全前移，比上线后救火便宜得多。