过去几年 API 呈爆炸式增长，人人都在建微服务、暴露接口。但这些 API 往往仓促构建，开发者没时间吃透所用技术，决策时常牺牲安全性。更棘手的是，生成式 AI 既能帮我们写代码，也被用来加速编写攻击 API 的脚本——数据暴露更多、攻击工具更成熟，双向放大了风险。
API 爆炸式增长，却常被仓促构建；生成式 AI 既能写代码也能写攻击脚本。本文编译自 Nordic APIs 对 Curity 专家 Michal Trojanowski 的访谈（2023），讲清 API 安全威胁与 OAuth 扩展护城河。
过去几年 API 呈爆炸式增长，人人都在建微服务、暴露接口。但这些 API 往往仓促构建，开发者没时间吃透所用技术，决策时常牺牲安全性。更棘手的是，生成式 AI 既能帮我们写代码，也被用来加速编写攻击 API 的脚本——数据暴露更多、攻击工具更成熟，双向放大了风险。
金融、政府向来是黑客的「肥羊」；而银行因合规（如开放银行）近期才暴露 API，反而更脆弱。在信息战背景下，新闻机构、NGO 也应提高警惕——这类攻击未必为窃取数据或牟利，可能只为植入虚假信息、未授权篡改内容。也就是说，API 攻击不只是「盗」，也可能是「改」。
OAuth 流程是客户端（OAuth 客户端）从授权服务器获取访问令牌的过程；现代主要用授权码流程。OAuth 是成熟协议，但也因此暴露了流程中的脆弱点，需要扩展来修补。典型例子是 PKCE（Proof Key for Code Exchange）：它原本用于防止一个移动应用窃取另一应用的授权码以拿到用户令牌，如今已建议每次令牌交换都使用 PKCE。
OAuth 扩展往往针对具体攻击或漏洞。例如 PKCE 保护授权码流程；mTLS（双向 TLS）可强化访问令牌；PAR（Pushed Authorization Requests）与 JARM（JWT Secured Authorization Response Mode）让授权请求与响应更安全。这些扩展组合起来，就是把「边界信任」升级为零信任——每次调用都验证、最小授权，从而系统性降低 API 被攻破的概率。