OWASP API 安全十大威胁深度解析(2019版)

深度解析:OWASP API Security Top 10 (2019) 终极指南与实战防御策略

1. 引言:API安全威胁态势与指南概述

1.1 现代架构中的API与日益严峻的挑战

在现代软件架构中,无论是基于微服务、云计算还是新兴的AI应用,应用程序接口(API)都充当着数据交换和业务逻辑执行的核心枢纽 1。API不仅是服务的生命线,也成为了组织面临网络安全威胁的最主要攻击面。

当前的威胁态势异常严峻。数据显示,2024年上半年,全球范围内新增的安全漏洞数量已达到11,075个,其中高危漏洞数量高达4,787个 2。作为Web应用的主要接口,API正承受着前所未有的压力。同一时期,Web应用防火墙(WAF)监测并防护的攻击次数达到了1,417.1亿次,攻击次数相比2023年上半年激增了61.39%,平均每天遭受7.87亿次攻击 2。这种爆炸性的增长表明,API防御工作已成为平台工程和安全负责人的首要任务 3。

1.2 OWASP API Security Top 10 (2019) 的核心价值

OWASP API Security Top 10 列表旨在为开发人员和安全团队提供一套标准化的风险参考,帮助他们理解并优先处理针对API的最常见且最具破坏性的漏洞。2019年版本全面概述了当时面临的十大主要威胁,为建立结构化的API安全策略提供了坚实的指导基础。

1.3 风险演进:从2019到2023的视角转换

虽然本报告的核心是分析2019版列表,但理解API安全威胁的演进趋势至关重要。对比2019版和2023版,可以发现API安全风险正朝着更加专业化、聚焦于业务逻辑缺陷的方向发展 4。

在2023年的更新中,一些被视为通用Web应用风险的项目被移除,例如:注入(Injection, API8:2019)和日志记录与监控不足(Insufficient Logging & Monitoring, API10:2019) 4。这并非意味着这些风险不重要,而是因为它们在API环境中并未表现出独特的攻击特性或利用方式,可以由通用安全实践(如OWASP Top 10 Web Application Security)覆盖。

与此同时,列表强化了针对API的特有风险:

  1. 授权逻辑的持久性威胁: 越权对象访问漏洞(BOLA, API1)和越权功能访问漏洞(BFLA, API5)是仅有的三个在2019版和2023版中都保持不变的风险类别 5,这有力地证明了授权机制的缺陷是API架构中最普遍且最难解决的挑战。
  2. 资源限制的范围扩大: 资源与速率限制不足(Lack of Resources & Rate Limiting, API4:2019)升级为不受限制的资源消耗(Unrestricted Resource Consumption, API4:2023) 4。这种变化强调,除了传统的API调用速率限制外,防御范围必须扩大到包括执行超时、最大允许内存、最大进程数等系统级限制,以确保API的正常运行并防止资源耗尽攻击 4。

下表提供了2019版列表作为当前分析的参照基准,并与最新演进进行了对比。

API Security Top 10 风险对比 (2019 vs 2023)

2019 版 (本报告焦点) 2023 版 (演进/对照) 主要变化
API1: Broken Object Level Authorization (BOLA) API1: Broken Object Level Authorization 维持第一大威胁,未变
API2: Broken Authentication API2: Broken Authentication 维持不变
API3: Excessive Data Exposure API3: Broken Object Property Level Authorization 风险细化,强调属性级别授权控制
API4: Lack of Resources & Rate Limiting API4: Unrestricted Resource Consumption 范围扩大,纳入执行超时、内存限制等系统资源 4
API5: Broken Function Level Authorization (BFLA) API5: Broken Function Level Authorization 维持不变
API8: Injection (已移除) 被视为通用Web应用风险,非API特有 4
API10: Insufficient Logging & Monitoring (已移除) 被视为通用Web应用风险 4

2. API安全核心:授权与访问控制失败 (API1, API5)

授权机制的缺陷是API安全的基石性问题,一旦出现问题,即使是复杂的应用也可能被简单地绕过。

2.1 API1:越权对象访问漏洞 (BOLA / IDOR) 深度剖析

越权对象访问漏洞(Broken Object Level Authorization, BOLA),也被称为不安全的直接对象引用(IDOR),是API架构中最普遍且最具影响力的授权逻辑缺陷 6。此漏洞的核心在于:用户已通过身份验证(AuthN),但在访问特定数据对象时,系统未能执行或错误地执行了对象级别的访问控制(AuthZ)。

2.1.1 攻击向量与危害

API端点通常会暴露处理对象标识符的接口,从而形成巨大的对象级别访问控制攻击面 7。攻击者可以通过简单地修改请求中暴露的对象ID来利用BOLA。这些ID可以是路径参数、查询参数、请求头(Header)中的值,甚至是请求体(Payload)中的数据。无论对象ID是可枚举的顺序整数、难以预测的UUID还是通用字符串,如果服务器没有将请求的用户ID与请求的对象ID进行严格的关联性验证,攻击者就可以越权访问其他用户的资源 6。

BOLA的危险性在于其极易利用性。攻击者只需了解URL或API请求的工作原理,便可尝试更改ID进行越权访问 6。更严重的是,攻击请求通常结构合规,不会触发基于签名的WAF或网关警报,使得漏洞难以被传统手段检测。

2.1.2 真实案例分析

BOLA并非理论风险,而是导致大规模数据泄露的实际威胁:

  • Uber (2016): 攻击者通过操纵API请求中的用户ID,获取了Uber司机和乘客的个人信息 8。
  • Parler (2021): 研究人员利用BOLA漏洞,通过递增对象ID的方式下载了大量未受保护的媒体文件,绕过了访问控制 8。
  • 其他案例: Experian、LinkedIn和Venmo的API泄露事件也曾导致数百万用户记录的暴露,其根源在于授权逻辑不足 6。

这些案例揭示了一个关键的安全缺陷:服务器端通常不完全追踪客户端状态,而是过度依赖客户端发送的ID参数来决定访问哪个对象 7。将当前会话的用户ID(例如,从JWT令牌中提取)与易受攻击的ID参数进行简单比较,往往不足以解决BOLA问题。

2.1.3 BOLA攻击流程时序图

以下Mermaid时序图展示了一个典型的BOLA攻击流程,其中业务逻辑服务器错误地跳过了对象所有权验证(AuthZ),导致数据泄露。

2.1.4 防御策略:强制执行对象级授权检查

针对BOLA的防御必须深入到应用代码的业务逻辑层:

  1. 强制对象级授权检查: 任何接收对象ID并对该对象执行操作的API端点,都必须在服务器端实施对象级别授权检查 7。此检查必须验证当前登录用户是否拥有对所请求对象执行操作的权限。
  2. 避免可枚举ID: 避免在API中暴露顺序或容易猜测的对象ID。使用全局唯一标识符(UUIDs)或经过哈希处理的ID可以提高枚举攻击的难度。

2.2 API5:越权功能访问漏洞 (BFLA)

越权功能访问漏洞(Broken Function Level Authorization, BFLA)与BOLA不同,它侧重于用户对整个API功能(或一组功能)的访问权限,而非单个数据对象。例如,普通用户可能通过尝试访问管理界面的API端点来执行管理功能。

防御BFLA的关键在于在API网关和每个业务处理单元中,实施严格的基于角色的访问控制(RBAC)。系统必须验证用户是否被授权访问特定的端点路径和HTTP方法,确保低权限用户无法访问高权限功能,例如管理面板或内部调试接口。

3. API2: 身份验证失效(Broken Authentication)

身份验证失效威胁着API的基础信任链,通常涉及不安全的令牌生成、会话管理缺陷以及对外部数据泄露的防御不足。

3.1 凭证填充与会话管理攻击

身份验证失效的主要攻击包括暴力破解、字典攻击,以及危害最大的凭证填充(Credential Stuffing)。凭证填充利用了用户在多个平台上重复使用相同或相似密码的习惯 9。攻击者从一个数据泄露事件中获取凭证,然后系统性地在成千上万的其他服务上尝试这些凭证,目标是实现账户接管(ATO) 9。

这种攻击的危害具有强大的外部关联性:目标API可能本身的身份验证机制是安全的,但由于用户密码在外部平台泄露,导致目标API受害。例如,2024年发生的通用汽车(GM)凭证填充攻击中,攻击者获取了65个客户账户,并成功访问了客户姓名、家庭住址、购买历史和支付信息 9。

3.2 高级防御体系

为了有效抵御身份验证失效,需要多层次的防御:

  1. 多因素认证(MFA): 实施MFA是抵抗凭证填充攻击最有效的手段之一,即使攻击者获得了正确的密码,也无法通过二次验证 10。
  2. Bot 缓解与威胁情报: 在API网关或WAF层部署先进的Bot检测和缓解机制,以识别并阻止大规模、自动化、分布式的登录尝试。同时,安全团队应整合威胁情报,监测已泄露的凭证列表,并在发现自家用户凭证泄露时强制重置密码 9。
  3. 安全的会话管理: 确保所有会话令牌(如JWTs)通过HTTPS传输。令牌应具有合理的、短暂的过期时间,并且在用户注销、密码更改或检测到异常活动时,能够可靠且及时地失效。

4. 数据暴露与资源滥用风险 (API3, API4, API6)

4.1 API3:敏感数据过度暴露(Excessive Data Exposure)

过度数据暴露的本质是API泄露了内部或敏感数据,而这些数据对于客户端执行其当前功能是不必要的。这种风险的根源在于开发者为了追求开发速度和便利性,选择了“Over-fetching”的做法——即返回完整的数据库模型,而不是使用精细裁剪后的数据传输对象(DTOs) 11。

这种做法是一种“沉默的威胁” 11,因为它放大了其他漏洞(如BOLA)的危害,导致敏感信息泄露的范围扩大。开发团队错误地依赖客户端来进行数据过滤或隐藏字段,但攻击者可以直接拦截和分析原始API响应体。

4.1.1 防御核心:强制服务器端过滤

OWASP强烈建议,绝不能依赖客户端执行信息过滤 12。所有数据过滤必须在API层面完成,确保每个客户端只接收到执行其功能所绝对必需的信息 12。

  1. 数据分类与审查: 对所有API处理的敏感和个人身份信息(PII)进行分类,并定期审查API如何使用这些信息,避免在非必要时发送。
  2. 架构校验: 利用API网关实施响应体校验。通过定义严格的JSON Schema或OpenAPI规范,网关可以强制输出模型符合安全标准,并防止敏感数据在响应中无意泄露 1。

4.2 API4:资源与速率限制不足(Lack of Resources & Rate Limiting)

缺乏资源和速率限制是导致API拒绝服务(DoS)或数据批量泄露的主要原因。如果API没有限制单个用户或IP的请求频率,攻击者可以轻易地通过自动化工具进行暴力破解、凭证填充或大规模数据爬取。

在现代威胁环境下,防御范围必须超越传统的速率限制:

  1. 系统资源限制: 参照API4:2023的演进,除了基于IP、用户或会话的API调用频率限制外,必须在代码和运行时环境中设置执行超时(Execution Timeouts)、最大允许内存和最大进程数 4。这些限制可以防止单个复杂的恶意请求耗尽系统资源,从而导致整个服务中断。
  2. 流量整形: 利用API网关和负载均衡器,实施精细化的流量整形策略,区分合法用户和潜在的恶意流量。

4.3 API6:批量赋值(Mass Assignment)

批量赋值漏洞发生在服务器自动将客户端请求体中的数据映射到内部数据模型或数据库对象时,而未能过滤掉不应由用户控制的属性。

攻击者可以尝试在请求中添加未经授权修改的属性,例如在用户注册或更新请求的Payload中插入 {“is_admin”: true} 或 {“account_balance”: 999999}。如果后端框架(如ORM)自动将这些输入映射到数据模型,攻击者将越权获得高权限或修改敏感数据。

防御批量赋值的核心是采用白名单机制

  1. DTOs强制使用: 使用专门的数据传输对象(DTOs),明确指定API允许接收和修改的字段。
  2. 严格的模型绑定: 确保ORM或框架仅更新那些被明确允许更新的属性列表,拒绝任何未在白名单中的字段。

5. 配置与部署环节的漏洞 (API7, API9)

5.1 API7: 安全配置错误(Security Misconfiguration)

安全配置错误是一个广泛的类别,涵盖了从操作系统、数据库、API网关、微服务组件到自定义代码的任何环节的错误配置。常见的例子包括:使用默认的、不安全的配置;CORS(跨域资源共享)配置不当导致数据被恶意域访问;暴露冗余或敏感的HTTP Header;以及使用不安全的TLS/SSL配置。

防御重点:

  • 集中化配置管理: 利用API网关作为策略执行点,集中管理所有安全相关的配置,例如TLS加密、HTTP安全头(如HSTS)和访问控制列表 3。
  • 环境隔离: 严格区分开发、测试和生产环境的配置,确保生产环境禁用所有调试功能和不必要的服务。
  • 持续审计: 定期对整个架构堆栈进行自动化安全审计,以识别和修复不安全的默认设置或配置漂移。

5.2 API9: 资产管理不当(Improper Assets Management)

API资产管理不当的核心风险在于缺乏对所有API端点、版本、服务和环境的完整、准确清单。这种缺失导致“影子API”(Shadow APIs)的出现,即那些已经被弃用、未受管理或暴露了调试功能的旧版本或内部端点 13。

自动化API发现工具通常依赖现有的负载均衡器、API网关或Ingress控制器提供的可见性来构建安全态势视图 3。这意味着绕过这些架构组件的影子API将成为安全盲区,构成巨大的未受保护的攻击面。

防御措施:

  1. 清单强制管理: 维护一份最新的API资产清单,精确记录所有API的版本、服务所有者、流量模式和数据敏感度。
  2. 持续发现与淘汰: 结合自动化API发现工具和严格的代码审查流程,持续监控和识别所有正在运行的API。对于不再使用的API版本(如V1),应强制下线并移除,避免暴露废弃的、存在安全隐患的端点 3。

6. 通用安全风险与高级防御架构

6.1 API8: 注入漏洞 (Injection) 与 API10: 日志记录与监控不足 (Insufficient Logging & Monitoring)

尽管在2023版本中,注入和日志记录不足被移除,但它们仍是保障API安全的基本要素。

  • 注入(Injection, API8:2019): SQL注入、NoSQL注入和命令注入仍然是底层威胁。防御依赖于严格的输入验证、数据清理以及在所有数据库交互中使用参数化查询。
  • 日志记录与监控不足(Insufficient Logging & Monitoring, API10:2019): 强大的可观测性和日志分析是发现和响应安全风险的基础 1。安全团队必须确保记录所有关键事件,特别是身份验证失败(API2)、授权失败(BOLA/BFLA)、输入校验失败和速率限制触发事件,以便在攻击发生后进行追踪和取证。

6.2 专家防御架构:API安全网关与运行时保护

在现代架构中,没有任何单一技术可以全面识别或防御所有的API威胁 3。API安全必须采用多层纵深防御,并将API运行时保护(API Runtime Protection)视为核心策略。运行时保护旨在将安全性融入平台基础设施和API代码中,实时识别和阻止恶意API请求 3。

API网关是实施纵深防御的关键,因为它处于流量路径的前端,能够串联执行多项安全检查:

  1. 策略执行与AuthN/AuthZ: API网关执行并强化安全策略,包括身份验证、授权、速率限制、访问控制列表和加密,有效防御API2和API5的风险 3。
  2. 数据校验与合规性: 网关可利用OpenAPI或JSON Schema严格校验用户请求体和服务端响应体 1。这对于防御批量赋值(API6)和过度数据暴露(API3)至关重要,确保请求符合规范,并防止敏感数据在响应中泄露。
  3. 数据主权与合规性: 对于涉及全球部署的应用,尤其是AI应用,API网关可以根据用户来源判断并确定请求应访问哪个服务器或数据存储区,以确保训练数据和用户生成的数据符合地区数据合规法规(如GDPR) 1。

以下流程图展示了API网关作为防御链的关键节点,如何通过多步骤校验来应对OWASP Top 10风险。

API 网关安全检查流程图 (防御链)

7. 结语与展望

API安全是一个持续的、跨职能的工程挑战。2019年OWASP API Top 10列表的核心价值在于其清晰地指出了API开发中最常发生的逻辑错误和配置疏忽。时至今日,越权对象访问(BOLA)、身份验证失效和过度数据暴露仍然是API面临的头号威胁。

API安全工作必须以有组织的方式推进,平台工程和安全负责人必须紧密合作,确保在整个API生命周期中满足安全需求 3。这包括清晰掌握API数量(资产管理)、进行有效的错误测试(API安全测试),并将安全机制纳入到代码和基础设施中(API运行时保护) 3。

随着技术架构的不断演进,安全团队还需要关注新兴威胁,例如2023版新增的“不安全的API消费”(Unsafe Consumption of APIs),它强调了开发者过度信任第三方API数据,导致集成服务成为攻击跳板的风险 13。持续的安全态势管理和采用API网关等关键技术实施纵深防御,是确保现代应用环境安全的核心策略。

核心API风险防御措施清单 (专家速查)

OWASP 2019 风险 主要攻击向量 架构级防御 (API 网关/WAF) 代码级防御 (授权/逻辑)
API1: BOLA ID 枚举/修改参数 强制执行身份验证/授权策略 始终进行对象级别访问控制检查 (AuthZ) 7
API2: 身份验证失效 暴力破解/凭证填充 Bot 缓解机制、速率限制、威胁情报 9 实施MFA、使用安全的JWT机制
API3: 过度数据暴露 Over-fetching/客户端过滤信任 响应体校验 (JSON Schema) 1 强制实施服务器端数据过滤 (DTOs) 12
API4: 资源限制不足 拒绝服务 (DoS) 速率限制、流量整形 设置执行超时、限制内存和CPU消耗 4
API6: 批量赋值 注入高权限属性 请求体校验 采用白名单机制,使用 DTOs 隔离输入
API9: 资产管理不当 弃用版本、影子API API网关强制版本控制、集中API清单 13 持续自动化API发现、定期代码审查 3

引用的著作

  1. 六大安全措施,教你如何使用API 网关保护AI 应用 - 支流科技, 访问时间为 十一月 23, 2025, https://www.apiseven.com/blog/best-practices-for-securing-your-ai-apps-by-api-gateway
  2. 2024年上半年度网络安全态势研判分析报告(第9期) - 澎湃新闻, 访问时间为 十一月 23, 2025, https://m.thepaper.cn/newsDetail_forward_28267884
  3. 利用关键工具和最佳实践,保护API 免受攻击 - F5, 访问时间为 十一月 23, 2025, https://www.f5.com.cn/company/blog/nginx/prevent-api-attacks-with-essential-tools-and-best-practices-for-api-security
  4. What’s New in OWASP API Top 10 2023? | Indusface Blog, 访问时间为 十一月 23, 2025, https://www.indusface.com/blog/whats-new-in-owasp-api-top-10-2023/
  5. A Comparison of OWASP’s Top 10 API Security Risks for 2019 and 2023 (The Evolution of … - Blog, 访问时间为 十一月 23, 2025, https://blog.entersoftsecurity.com/owasps-top-10-api-security-risks-for-2019-vs-2023/
  6. Understanding Broken Object Level Authorization (BOLA): OWASP API Security Principle #1, 访问时间为 十一月 23, 2025, https://www.apisec.ai/blog/understanding-broken-object-level-authorization-bola-owasp-api-security-principle-1
  7. API1:2023 Broken Object Level Authorization - OWASP API Security Top 10, 访问时间为 十一月 23, 2025, https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/
  8. Broken Object Level Authorization (BOLA): The Silent Threat in API Security - Medium, 访问时间为 十一月 23, 2025, https://medium.com/@bubu.tripathy/broken-object-level-authorization-bola-the-silent-threat-in-api-security-2fe5f57b21b2
  9. Day 3: Broken Authentication — When Your Digital Bouncer Is Actually Working for the Other Team - Medium, 访问时间为 十一月 23, 2025, https://medium.com/@anonwiz8/day-3-broken-authentication-when-your-digital-bouncer-is-actually-working-for-the-other-team-1682edc2ff80
  10. Credential Stuffing: How It Works & 4 Real-World Attacks - Seraphic Security, 访问时间为 十一月 23, 2025, https://seraphicsecurity.com/learn/website-security/credential-stuffing-how-it-works-and-4-real-world-attacks/
  11. The API vulnerabilities nobody talks about: excessive data exposure - Blog Detectify, 访问时间为 十一月 23, 2025, https://blog.detectify.com/best-practices/the-api-vulnerabilities-nobody-talks-about-excessive-data-exposure/
  12. Excessive Data Exposure - What is Bright DAST?, 访问时间为 十一月 23, 2025, https://docs.brightsec.com/docs/excessive-data-exposure
  13. OWASP Top 10 API Security Risks – 2023, 访问时间为 十一月 23, 2025, https://owasp.org/API-Security/editions/2023/en/0x11-t10/