OWASP 十大 API 安全风险：2023 年版终于问世

OWASP 和 Akamai 都在不断发现对象级别的重大风险，所以说 BOLA 仍然是排在第一位、严重性最高的 API 安全风险，务必要引起重视。 

但如果再往下深入一层到对象属性级别，就会发现还存在过度共享信息的附加风险，或是允许修改或删除一些本不应修改或删除的特定属性。

具备针对 BOLA 的安全防护并不代表也能抵御 BOPLA，而我们将“过度数据暴露”和“批量分配”类别组合成为一个单独的类别，目的就是着重提醒 API 开发人员关注对象内的属性。

对于正在选择 API 安全保护产品的用户来说，这种差别非常重要，因为他们需要确保自己选择的产品能够同时涵盖这两种类型的攻击。

上榜风险 | API6:2023 | 服务器端请求伪造

OWASP 降低了“注入”的安全风险级别，因此这项风险掉出十大风险榜单，让位给 服务器端请求伪造 (SSRF) 。 

SSRF 这种类型的攻击会利用 Web 应用程序或 API 中的漏洞，使攻击者能够从服务器向其他内部或外部系统发送未经授权的请求。

以下介绍了 OWASP 选择作出这一改变的两个潜在原因： 

• API 更容易遭受 SSRF 攻击，因为它们依赖于 Kubernetes 和 Docker 这样的现代技术，而这些技术又需要采用基于 HTTPS API 的通信协议。
• 凭借 Webhook、SSO 集成以及 URL 文件获取/通过 API 端点重定向等手段，攻击者将有机会实施 SSRF 攻击。

深入探究

如需深入探究 SSRF 攻击，请阅读 Mike Elissen 的文章 《您的 API 正在帮助实施服务器端请求伪造 (SSRF) 攻击》(Your APIs Are Enabling Server-Side Request Forgery (SSRF) Attacks)。

下榜风险 | API8:2019 | 注入

对整个 API 安全保护界来说，从榜单中移除“注入”风险都是一既大胆又有争议的举动，但在 API 端点上，“注入”攻击的威胁确实在减少。 

现在，“注入”基本上已经成为了 API8:2023 | 安全配置错误的一部分。适当的安全配置应该包括 Web 应用程序和 API 保护机制，而这种机制应该能默认扫描和预防注入攻击。

GraphQL 正在逐渐成长为一种 API 技术。其核心是一种查询语言，可能会助长注入攻击卷土重来的势头，所以依赖 GraphQL 的 API 开发人员应该继续对此保持警惕。

新增风险 | API4:2023 | 不受限制的资源消耗

最初的列表将重点特别放在了解资源消耗的风险上，它会导致 API 端点不堪重负（还有可能变为不可用状态），从而损害用户体验。 

如今的 API 端点需要保持可用性，但仅有可用性还不够。实施 API 网关、负载平衡或速率限制就是在正确的道路上踏出了一步。 

最近几年，我们发现“API 使用经济”发生了巨大的变化。这个 更新的类别 旨在培养这方面的意识，而这个方面的风险将随着第三方 API 的集成不断发展。

新增风险 | API6:2023 | 不受限制的敏感业务流访问

另一种新增的风险是 API6:2023 不受限制的敏感业务流访问。这一类别最终解释清楚了安全防护如此特殊的原因：要从攻击者的视角出发，思考哪里存在潜在收益。

技术（此处指 API）只是执行业务逻辑的一种方式，而通过技术手段绕过或改变业务逻辑的方法并非理想方法，甚至有可能造成情况复杂化。

OWASP 分享了几个如何防止情况复杂化的示例，但只有支持 API 端点的业务逻辑才会存在这种安全风险。

API 开发人员：示例

最近，Mike Elissen 与 API 开发人员进行了一场关于流媒体服务的对话。为了吸引新用户，这项流媒体服务为他们提供了免费的 30 天试用，他们需要提供自己的信用卡信息。 

但是，业务逻辑对于新注册用户的认定方式就是电子邮件地址不重复。用户只要注册一个新的电子邮件地址，就能轻松获得一次新的试用权——尽管使用的信用卡信息相同，这促使用户每个月都创建新的帐户，无限期地免费使用该服务。 

新增风险 | API10:2023 | 不安全的 API 使用

随着第三方的 API 使用 快速增长，API 通常不得不与各种内部和外部（第三方）系统进行集成和通信，包括发送和接收数据。

在此类情况下，遵循“基本的”安全规则同样非常重要，而对于安全产品来说，这方面的漏洞检测和主动防御可能会变得较为复杂。 

OWASP 在其文档中提供了一系列建议，有些建议具有普遍性，还有些具体针对 API，例如：

• 遇到重定向时要保持谨慎。在业务逻辑中纳入这一方面的监管，同时添加能持续监控和检查流量的安全解决方案。
• 即使第三方 API 的信誉良好，也不能轻易相信。在自己的应用程序和 API 端点中建立防御机制和限制条件。

Akamai 可以帮助实施 API 安全保护

企业与其安全供应商必须紧密合作，在人员、流程和技术方面保持一致，以建立坚实的防御来应对 OWASP 十大 API 安全风险中概述的安全风险。 

Akamai 提供了业界卓越的安全解决方案，还有经验丰富的专家和 Akamai Connected Cloud，每天从数以百万计的 Web 应用程序攻击、数以亿计的爬虫程序请求和数万亿的 API 请求中获取见解。借助 Akamai 的 Web 应用程序和 API 安全解决方案，您可确保贵企业能够抵御较为高级的 Web 应用程序攻击、分布式拒绝服务攻击以及基于 API 的攻击。 

Akamai + Neosec

新一期 OWASP 发布之际，我们刚好收购 Neosec不久。Neosec 的 API 安全解决方案将对 Akamai 出色的应用程序和 API 安全产品组合形成补充，可以在不断演变的 API 威胁态势下助力 Akamai 开疆拓土。 

这一强强联合带来的优势可以帮助客户发现他们的所有 API、评估其中的风险，并对漏洞和攻击作出响应，从而使客户能够轻松保护自己的 API。

了解更多

详细了解 Akamai 的 API 安全解决方案 以及我们 收购 Neosec的举措。 

祝贺 OWASP，同时也借此机会对 OWASP 深表感谢！

安全意识的培养需要整个业界付出巨大努力，我们非常欣赏 OWASP 在这其中发挥的带头作用。特别感谢 Erez Yallon、Inon Shkedy 和 Paulo Silva 在 2023 年版中的辛勤工作。 

同时，我们还要感谢所有人的群策群力，特别是 Akamai 的 Maxim Zavodchik 和 Mike Elissen ，他们不但参与了该项目，还积极帮助更广泛的开发人员群体深入了解 API 安全防护。

关于 API 的其他信息

在 Akamai 的互联网现状 (SOTI) 报告中，我们对 API 的使用情况和 API 流量进行了跟踪。阅读 往期 SOTI 报告 了解更多信息，并关注我们每个季度发布的全新 SOTI 报告。

其他资源

系列视频： 《API 安全基础知识》(Fundamentals of API Security)

博文： 《OWASP 十大 API 安全风险的新变化对您有何影响》(What Proposed New Changes in the OWASP API Security Top 10 Mean for You)