据 Raidiam 发布的一项评估报告显示，大多数组织通过 API 暴露了敏感数据，却未部署足够的安全控制措施，且往往对此毫无察觉。

该报告基于对 68 家不同行业组织的深入评估，特意排除了如英国开放银行（UK Open Banking）这类已受到严格监管的环境，旨在了解在缺乏监管压力的情况下，企业对 API 安全的真实防护水平。而结果令人担忧。

超过 80% 的组织被归入“需紧急整改”级别。这些公司普遍通过 API 处理高价值的个人或支付类数据，却仍在使用静态 API 密钥、长期有效的 Bearer Token，或使用共享密钥的基础 OAuth 等 过时或脆弱的身份认证手段。在所有受评组织中，仅有一家部署了被认为“现代化”的 API 安全体系，包括客户端证书认证、受限 Token（Sender-Constrained Tokens）和双向 TLS（mTLS）。

研究人员指出，数据敏感性与安全控制之间的落差，正是此次报告想要强调的核心问题。“在依赖 API 的程度快速增长的同时，绝大多数组织的安全加固却远远滞后，”报告警告道。

API 安全的“脆弱地基”

如今，API 已成为移动应用、云服务与合作伙伴集成的核心支撑。这也意味着攻击面正在急剧扩大，而防护措施却未随之演进。当前，API 涉及的内容已涵盖身份声明、持卡人信息、健康数据及账户信息等多个高风险领域，但许多组织仍未将 API 纳入正式的安全治理体系中。

报告指出，仅有 27% 的组织具备对其 API 所暴露敏感数据的可视性；不到一半会进行诸如模糊测试（fuzzing）或动态分析的 API 专项安全测试；而API 级别的持续监控更是严重缺失，这意味着攻击者可能在长达数周的时间里反复探测或滥用 API 而不被发现。

安全标杆：监管领域的借鉴

Raidiam 明确指出，应对 API 安全风险的解决路径，其实早已在受监管行业中得到验证。例如，金融级 API 通常采用双向 TLS 来强制验证客户端与服务端身份，显著提升了攻击者伪造合法应用身份的难度。同时，使用绑定证书的访问令牌，可有效防止 Token 被盗用后继续访问系统。

这些措施并非“理论方案”。在英国、欧洲、澳大利亚等地，开放银行等行业规范早已强制实施此类安全控制，英国所有银行都已部署相关机制。但在缺乏监管压力的其他行业，类似控制措施的落地率依然极低。

这导致了一个明显的“两极分化”：一类企业已将 API 视为核心基础设施并纳入安全治理，而另一类则仍将其视为普通开发工具，对安全性投入不足。

Raidiam 企业战略负责人 David Oppenheim 表示：“虽然大多数组织在 API 安全方面严重滞后，但在监管驱动或自发行动下推进安全升级的银行、国际卡组织等机构，已在规模与安全成熟度上遥遥领先。”

Oppenheim 指出，董事会层面的治理并不要求精通技术。“尽管 API 安全涉及高度技术细节，但仍有明确而有效的管理视角。比如：董事会可以询问组织是否采用了 FAPI（金融级 API）等国际标准，是否有对当前 API 安全状态进行成熟度评估并建立改进路径。”

他还建议从一个简单却关键的指标开始：“例如，统计当前仍依赖静态密钥或共享密钥的 API 集成比例，并设定迁移至加密认证机制的时间表。这个 KPI 能够清晰地体现安全改善进度，便于非技术管理者监督。”

结构性变革正悄然推进

目前，API 安全性提升的主动力量主要来自于直接监管或行业自律，但新的合规压力正在浮现。

“企业规模也决定其行动节奏，”Oppenheim 补充道，“大型企业和关键基础设施提供商已开始主动提升 API 安全 —— 不仅在银行业，也包括支付与身份认证平台 —— 因为他们认识到：强大的 API 安全能力是未来规模化和可信运营的基础。”

与此同时，合规“追风口”正在形成：TLS 基线要求正在收紧，未来将影响所有数字业务；DORA（数字运营弹性法案）等法规也在推动对第三方 API 风险的全新监管预期。

架构趋势同样助推 API 安全进化。“NIST 零信任架构已成为许多企业改革参考蓝图。在这一思路下，利用 PKI 或 mTLS 实现强身份认证，是构建可验证、防御性系统的关键路径。”

API 安全风险已成为企业数字化运营中的“隐形高危区”。
无论监管是否到来，CISO 与董事会层面的主动治理，才是改变风险格局的关键突破口。