OWASP API Security Top 10

概述

随着微服务架构、单页应用（SPA）和移动应用的普及，API（应用程序编程接口）已成为现代应用程序通信的核心纽带。与传统 Web 应用相比，API 具有自动化程度高、暴露面广、数据交换频繁等特点，由此带来的安全挑战也截然不同。

OWASP（Open Web Application Security Project，开放 Web 应用安全项目）于 2019 年首次发布了 API Security Top 10，并于 2023 年发布了重大更新版本。OWASP API Security Top 10 2023 版针对 API 特有的安全风险进行了系统性梳理，是 API 安全评估、安全开发和渗透测试的重要参考标准。

本文将对 OWASP API Security Top 10 2023 中的十大风险逐一进行深入剖析，涵盖风险描述、攻击示例和防御方案，并对比其与传统 Web OWASP Top 10 的异同，最后提供 API 安全排查清单以辅助实际操作。

API1:2023 — 对象级授权失效（Broken Object Level Authorization）

风险描述

对象级授权失效是 API 安全中最常见且最严重的安全问题。当 API 在处理对特定对象的访问请求时，未能正确验证当前用户是否具有对该对象的操作权限，就会导致此类漏洞。简单来说，如果用户 A 可以通过修改请求中的对象 ID 来访问或操作用户 B 的数据，那么就存在对象级授权失效问题。

这类漏洞的本质在于：API 通常通过参数（如 URL 路径、查询参数或请求体中的 ID）来指定要操作的对象，但如果服务端只验证了用户的身份验证令牌（Token），而没有验证该用户是否是该对象的合法所有者或具有相应权限，就会产生越权访问。

攻击示例

假设有一个电商 API，用户通过以下请求查看订单详情：

GET /api/v1/orders/1001
Authorization: Bearer <user_a_token>

如果服务端仅根据订单 ID 1001 查询并返回订单数据，而未验证当前用户是否为该订单的所属者，那么攻击者只需遍历订单 ID 即可获取其他用户的订单信息：

GET /api/v1/orders/1002
Authorization: Bearer <user_a_token>   // 返回 user_b 的订单数据
GET /api/v1/orders/1003
Authorization: Bearer <user_a_token>   // 返回 user_c 的订单数据

防御方案

在每一个需要访问数据对象的 API 端点中，将当前认证用户的身份信息作为查询条件的一部分，强制校验用户对目标对象的拥有权或权限。
使用随机化的、不可预测的对象标识符（如 UUID）替代自增数字 ID，以增加攻击者猜解对象 ID 的难度。但需注意，这仅是深度防御手段，不能替代授权校验。
实现统一的授权中间件或切面，确保所有 API 端点都经过一致的授权检查，避免遗漏。
编写自动化集成测试，覆盖不同角色用户之间的越权场景。
对于批量操作端点，同样需要逐条验证每个对象的访问权限。

API2:2023 — 用户身份认证失效（Broken User Authentication）

风险描述

用户身份认证失效是指 API 的身份认证机制存在缺陷，导致攻击者可以冒充其他用户身份进行 API 调用。由于 API 是无状态且高度自动化的，认证机制的薄弱点往往更加容易被大规模利用。

常见的问题包括：弱密码策略、凭证填充攻击防御不足、令牌（Token）泄露或未正确失效、缺乏多因素认证（MFA）、密码重置流程设计缺陷等。

攻击示例

攻击者通过数据泄露获得大量用户名和密码组合，然后针对 API 的登录端点发起自动化凭证填充（Credential Stuffing）攻击：

POST /api/v1/login
Content-Type: application/json

{
  "username": "admin@example.com",
  "password": "password123"
}

如果 API 未实施速率限制、未启用 CAPTCHA 或未检测异常登录行为，攻击者可以在短时间内批量尝试大量凭证，最终成功登录系统。

另一个常见的问题是 JWT 令牌未设置合理的过期时间，或者服务端未提供令牌撤销机制，导致令牌泄露后攻击者可长期使用。

防御方案

实施强密码策略（长度不低于 12 位，包含多种字符类型），并定期检查密码是否出现在已知泄露数据库中。
登录端点必须实施速率限制、账户锁定和异常检测机制，防范暴力破解和凭证填充攻击。
强制或提供多因素认证（MFA）选项，特别是针对管理账户和敏感操作。
使用短期有效的访问令牌（Access Token），搭配长期有效的刷新令牌（Refresh Token），并提供令牌撤销机制。
密码重置流程必须使用带有时效性的一次性链接或验证码，且链接应在使用后立即失效。
避免在 URL 中传递认证凭证，所有认证信息必须通过安全的请求头传递。

API3:2023 — 对象属性级授权失效（Broken Object Property Level Authorization）

风险描述

对象属性级授权失效是 API Security Top 10 2023 新增的类别，它关注的是 API 在返回或更新对象数据时，未能对对象内部的属性进行细粒度的权限控制。攻击者可能通过 API 读取到本不应暴露的敏感字段（如密码哈希、内部标识符），或者通过 API 修改本不应更改的字段（如用户角色、账户余额）。

这类问题在 RESTful API 和 GraphQL API 中都很常见。REST API 通常存在"过度数据暴露"（Excessive Data Exposure）问题，而 GraphQL API 则可能因为查询过于灵活导致未授权的属性访问。

攻击示例

场景一（读取侧）：用户信息 API 返回了完整的数据对象，包含不应暴露的敏感字段：

json

// GET /api/v1/users/me 的响应
{
  "id": 1001,
  "username": "alice",
  "email": "alice@example.com",
  "password_hash": "$2a$10$...",
  "internal_note": "高风险用户",
  "credit_card": "****-****-****-1234"
}

场景二（写入侧）：攻击者在更新用户资料时，尝试修改越权属性：

PATCH /api/v1/users/me
Content-Type: application/json

{
  "username": "new_name",
  "role": "admin",        // 尝试将自己提升为管理员
  "balance": 1000000      // 尝试修改账户余额
}

如果服务端直接将请求体映射到数据库模型进行更新，而未过滤允许修改的属性，攻击者即可实现权限提升或数据篡改。

防御方案

为每个 API 端点明确声明可返回和可修改的属性列表（白名单机制），而不是直接将内部数据模型暴露给客户端。
使用数据传输对象（DTO）或视图模型（View Model）来屏蔽不应暴露的内部属性。
对于更新操作，严格校验请求体中每个字段的修改权限，拒绝非授权的属性更改。
避免使用 user.update(req.body) 或类似的"全量更新"模式，必须指定可更新字段的白名单。
在 GraphQL API 中，实施字段级别的授权指令或解析器级别的权限检查。

API4:2023 — 资源消耗无限制（Unrestricted Resource Consumption）

风险描述

资源消耗无限制是指 API 未对客户端消耗的服务器资源进行合理限制，导致攻击者可以通过精心构造的请求耗尽服务端资源，造成拒绝服务（DoS）。这类问题在 API 层面表现得尤为突出，因为 API 通常需要处理复杂的数据查询和处理逻辑。

常见场景包括：分页参数过大导致数据库查询超时、复杂查询条件导致 CPU 密集计算、频繁的 API 调用导致连接池耗尽、请求体过大导致内存溢出等。

攻击示例

攻击者通过设置极大的分页参数，迫使 API 执行巨大的数据库查询：

GET /api/v1/products?page=1&pageSize=1000000

或者使用复杂、嵌套的 GraphQL 查询来触发深度超过预期的数据加载：

graphql

query {
  users {
    posts {
      comments {
        author {
          posts {
            comments { ... }
          }
        }
      }
    }
  }
}

再或者，攻击者上传超大文件到 API 的文件上传端点，耗尽服务端磁盘和内存资源。

防御方案

对所有分页、列表类 API 强制实施上限限制（如 pageSize 最大值设为 100），并对超出限制的请求直接拒绝。
限制请求体的最大大小，在反向代理（如 Nginx、API 网关）层配置即可阻挡大部分攻击。
对 CPU 密集型操作设置超时和并发限制，避免单个请求长时间占用服务资源。
对 GraphQL API 实施查询深度限制（Query Depth Limit）、查询复杂度分析（Query Complexity Analysis）和速率限制。
配置合理的连接池大小、线程池大小和数据库连接数，防止资源耗尽后的连锁故障。
实施速率限制（Rate Limiting），根据用户、IP 或 API Key 进行差异化限流。

API5:2023 — 功能级授权失效（Broken Function Level Authorization）

风险描述

功能级授权失效是指 API 未能对不同角色的用户进行细粒度的功能权限控制。当普通用户能够访问仅限管理员使用的 API 端点（如用户管理、系统配置、审批操作等）时，就存在功能级授权失效问题。

这类漏洞通常源于 API 设计时的疏忽——开发人员可能为管理功能实现了独立的 API 端点，但未在所有管理端点上实施严格的角色验证，或者仅在前端隐藏了管理入口，而后端未做任何权限校验。

攻击示例

假设系统包含以下管理 API：

GET    /api/v1/admin/users          // 列出所有用户
DELETE /api/v1/admin/users/{id}     // 删除用户
POST   /api/v1/admin/config         // 修改系统配置

如果这些端点仅在管理后台的前端代码中被隐藏，而后端仅检查用户是否提供了有效的 JWT 令牌（未检查角色是否为 admin），攻击者只需直接构造如下请求即可越权执行管理操作：

DELETE /api/v1/admin/users/1002
Authorization: Bearer <普通用户令牌>

防御方案

在每个管理/高权限 API 端点中，明确检查当前用户的角色和权限，而非仅依赖前端路由层面的权限控制。
采用统一的授权框架（如 RBAC、ABAC），使用注解或中间件声明的形式在代码层面强制实施权限校验。
将 API 路由按功能分组，对管理类路由使用独立的 Base URL（如 /api/v1/admin/*），并通过专门的安全中间件统一管理。
编写集成测试，覆盖不同角色用户对所有 API 端点的访问场景，确保权限控制无遗漏。
避免在 URL 或请求体中传递角色信息（如 "role": "admin"），角色和权限应由服务端从会话/令牌中获取。

API6:2023 — 对批量数据的不安全访问（Unrestricted Access to Sensitive Business Flows）

风险描述

此风险类别在 2023 版中进行了较大调整，聚焦于 API 未能有效防护敏感业务流被自动化滥用的问题。这类风险的特点是：单个 API 请求本身可能并无恶意，但通过自动化脚本大批量调用 API 来爬取数据、操纵业务逻辑或进行欺诈活动，就会造成严重危害。

典型场景包括：爬虫批量爬取商品价格进行竞品分析、自动化脚本大量创建虚假账户、机器人批量抢购限购商品、滥用票务 API 进行黄牛操作等。

攻击示例

某电商平台的商品搜索 API：

GET /api/v1/products?category=electronics&page=1&pageSize=50

搜索引擎优化工具或竞争对手每隔数秒就更换搜索参数调用此 API，每天爬取数十万条商品数据（名称、价格、库存信息），用于构建竞品价格监控平台。

另一个场景：在线票务平台的订单创建 API，正常用户一次可以购买 4 张票，但攻击者通过自动脚本同时发起数百个并发请求，一次性锁定大量座位，随后在二手市场高价转售。

防御方案

识别和标记业务敏感流（如数据爬取、批量注册、抢购等），对这些流程实施更严格的速率限制和行为分析。
实现基于行为的异常检测系统，识别人类用户与机器人的请求特征差异（如请求间隔是否过于规律、浏览器指纹、鼠标轨迹等）。
对敏感业务端点启用 CAPTCHA 或挑战-应答机制，增加自动化攻击的难度。
实施基于设备指纹的信任评分体系，对低信誉请求施加严格限制。
使用 API 网关或 WAF 产品中的机器人管理（Bot Management）功能。
对关键业务数据的导出频率和数量进行限制，并记录所有异常的高频访问行为。

API7:2023 — 服务端请求伪造（Server Side Request Forgery）

风险描述

服务端请求伪造（SSRF）是指攻击者通过构造恶意请求，诱使 API 服务端向内部网络或外部系统发起非预期的 HTTP 请求。在 API 架构中，SSRF 的利用面更广——API 服务端常常需要根据用户输入来获取外部资源（如获取 URL 内容、调用第三方服务），若未对目标地址进行充分校验，攻击者可利用这一功能访问内部网络资源。

SSRF 在云原生架构中危害尤为严重，因为攻击者可以通过 SSRF 访问云服务的元数据端点（如 AWS 169.254.169.254、Azure 169.254.169.254、阿里云 100.100.100.200）获取临时凭证，进而横向移动至整个云基础设施。

攻击示例

假设 API 提供了一个"上传头像"功能，允许用户输入图片 URL，服务端自动抓取该 URL 的图片内容：

POST /api/v1/user/avatar
Content-Type: application/json

{
  "avatar_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}

如果服务端未对 avatar_url 进行协议、域名和端口的校验，攻击者即可利用此功能访问云服务商的实例元数据服务，获取 IAM 角色的临时凭证，从而获得对云资源的未授权访问。

此外，攻击者还可以扫描内部网络的开放端口和服务：

{
  "avatar_url": "http://10.0.0.1:6379/"    // 探测内部 Redis 服务
}

防御方案

对外部资源请求实施严格的 URL 白名单，只允许访问可信的域或 URL 模式。
禁止访问内部 IP 地址段（如 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）和特殊用途地址（如 169.254.169.254）。
限制可用的网络协议（仅允许 https://，禁止 file://、ftp://、dict:// 等协议）。
在 DNS 解析层面进行二次校验，防止 DNS 重绑定攻击（DNS Rebinding Attack）。
使用独立的、网络隔离的服务端来执行外部资源请求，与核心 API 服务分离部署。
禁用或限制服务端 HTTP 客户端中的重定向跟随行为，避免绕过 URL 校验。

API8:2023 — 安全配置错误（Security Misconfiguration）

风险描述

安全配置错误是 API 安全中最容易被忽视但危害重大的问题。它涵盖了 API 栈中所有层面的安全配置不当，包括：服务器操作系统、Web 服务器、API 框架、数据库、第三方库、云服务配置等。

常见的配置错误包括：默认凭证未修改、调试模式在生产环境未关闭、跨域资源共享（CORS）配置过于宽松、未正确配置 HTTPS 和 HSTS、信息泄露（如错误堆栈信息暴露）、不必要的 HTTP 方法开放、缺少安全响应头等。

攻击示例

攻击者通过扫描常见 API 端点，发现某个 API 端点返回了详细的错误信息：

POST /api/v1/users
Content-Type: application/json

{
  "username": "",
  "email": "invalid"
}

响应：
HTTP/1.1 500 Internal Server Error
{
  "error": "SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'username' cannot be null",
  "trace": "com.example.api.UserController.createUser(UserController.java:42)"
}

从这个错误信息中，攻击者可以直接获取到数据库类型（MySQL）、表结构信息、后端语言和框架（Java/Spring）以及具体代码行号，这些信息对后续攻击具有极高的价值。

另一个常见问题是 CORS 配置不正确：

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

这样的配置允许任意域名发送跨域请求并携带凭据，意味着任何恶意网站都可以在用户浏览器中向该 API 发出经身份认证的请求。

防御方案

建立自动化的配置检查和基线扫描流程，定期检查 API 栈各组件的安全配置。
在生产环境中完全关闭调试模式和详细错误信息，返回通用错误提示，并将详细错误记录到日志系统。
严格配置 CORS，只允许特定的、受信任的源（Origin），不要在需要凭据的场景下使用通配符 *。
强制启用 HTTPS，配置 HSTS 头部，禁用不安全的 TLS 版本（TLS 1.0/1.1）和弱加密套件。
仅开放 API 所需的最小 HTTP 方法集（如 GET、POST、PUT、DELETE），禁用 OPTIONS、TRACE 等方法。
配置安全响应头：X-Content-Type-Options: nosniff、X-Frame-Options: DENY、Content-Security-Policy 等。
移除所有默认账号和默认配置，修改默认端口和默认路径。

API9:2023 — 库存管理不当（Improper Inventory Management）

风险描述

库存管理不当是 API Security Top 10 2023 中新增的一个重要类别，它关注的是组织对内部和外部 API 的全生命周期管理不足。随着微服务架构的普及，一个组织可能运行着数百甚至数千个 API 服务，如果不能清楚地掌握所有 API 的清单、版本、状态和依赖关系，就会出现严重的安全盲区。

典型问题包括：已废弃的 API 版本仍在线上运行且未得到安全维护、文档缺失或与实际实现不一致、测试环境和预发布环境的 API 暴露在公网、第三方 API 依赖和 API 网关后的隐藏 API 缺乏管理、API 版本管理策略缺失等。

攻击示例

某公司早期发布了 /api/v1/users 接口，后来进行了安全升级并发布了 /api/v2/users，但由于未及时下线旧版本，/api/v1/users 仍然可被外部访问。攻击者发现旧版本存在已知漏洞（如 SQL 注入、未授权访问），直接利用这些漏洞获取了用户数据。

另一个场景：团队的测试环境使用了生产环境的真实数据子集，并将测试 API 部署在公网可访问的地址（如 test-api.company.com），且使用了弱密码。攻击者通过子域名枚举发现了该测试 API，利用其薄弱的安全防护获取了部分用户数据。

防御方案

建立完整的 API 清单和资产管理体系，持续发现和记录所有 API 端点、版本、宿主、状态和负责人。
为每个 API 版本制定明确的生命周期管理策略，包括发布、弃用和下线流程。已弃用的 API 版本必须在规定时间内完全下线或隔离。
所有环境（开发、测试、预发布、生产）必须与生产环境数据进行严格隔离，测试环境 API 不应暴露在公网，或至少实施更强的访问控制。
维护 API 网关作为统一的 API 入口，隐藏内部 API 和已弃用的 API 版本，所有外部流量必须经过 API 网关。
建立 API 变更管理和安全评审流程，每次 API 变更都需经过安全评估。
定期审计和清理 API 密钥和访问令牌，移除不再使用的凭据。

API10:2023 — 不安全地使用API（Unsafe Consumption of APIs）

风险描述

不安全地使用 API 是 2023 版新增的风险类别，与前九类不同，它将视角从"API 提供者"转向了"API 使用者"。在微服务架构中，一个服务既可能是 API 提供者，也可能是其他 API 的消费者。当 API 消费者在使用外部或第三方 API 时缺乏安全意识和安全措施，就可能引入安全风险。

常见问题包括：过度信任第三方 API 的数据而未经充分校验、使用 HTTP 而非 HTTPS 调用 API、未正确验证第三方 API 的 TLS 证书、在应用中以明文存储 API 密钥或令牌、未对第三方 API 的响应进行完整性校验导致数据投毒等。

攻击示例

某应用集成了第三方天气服务 API，直接将其返回的数据解析并展示在用户界面中：

python

response = requests.get("http://weather-api.example.com/current?city=beijing")
data = response.json()

问题一：使用了 HTTP 而非 HTTPS，中间人攻击者可篡改 API 响应，在返回数据中注入恶意脚本，当应用将数据渲染到页面时触发 XSS 攻击。

问题二：应用未对第三方 API 返回的数据进行结构校验和内容过滤，攻击者可以通过劫持 DNS 或进行中间人攻击，返回包含恶意载荷的数据。

另一个场景：开发人员将第三方 API 的密钥硬编码在移动应用或前端代码中，攻击者通过反编译或网络抓包即可获取该密钥，冒用身份调用第三方 API 产生高额费用。

防御方案

所有对外部 API 的调用必须使用 HTTPS，并正确配置 TLS 证书验证（禁用证书验证绕过）。
对第三方 API 的响应数据进行严格的结构校验和内容过滤，不要盲目信任外部数据。
实施依赖 API 的故障隔离和熔断机制（Circuit Breaker），避免因第三方 API 的故障或异常响应导致自身服务崩溃。
使用专门的秘密管理工具（如 HashiCorp Vault、AWS Secrets Manager）存储和管理 API 密钥和令牌，避免硬编码。
对通过 API 获取的外部数据在存储和处理前进行数据清洗和验证。
为下游 API 调用添加超时配置，避免因第三方 API 响应过慢耗尽服务资源。
定期审计外包或第三方 API 集成的安全合规性，确保其安全标准与组织要求一致。

与 Web OWASP Top 10 的差异对比

对比维度	Web OWASP Top 10	OWASP API Security Top 10
关注对象	传统 Web 应用，以页面交互为主	API 端点，以数据交换和自动化请求为主
核心风险	XSS、注入、CSRF 等前端/交互类风险	授权失效、认证失效、资源滥用等后端逻辑类风险
会话管理	主要依赖 Cookie/Session	主要依赖 Token（JWT、OAuth2）、API Key
攻击面特征	浏览器-服务器，受浏览器同源策略保护	客户端-服务器，无浏览器保护，直接暴露业务逻辑
批量攻击风险	较低，受限于浏览器环境和用户交互	极高，API 天生适合自动化脚本大规模调用
XSS 排名	历史上长期位列前三	未单独列入，因其在 API 场景中危害相对较小
SSRF	A10:2021 新入榜	A07:2023，排名更靠前，反映 API 场景的高危性
授权漏洞	A01:2021 统一归为"访问控制失效"	细分为 A01（对象级）、A03（属性级）、A05（功能级）
数据暴露	较少关注	A03 重点覆盖，API 数据泄露风险远高于传统 Web
API 生命周期管理	不涉及	A09 和 A10 专属类别，反映微服务和 API 生态的独特需求

从上表可以看出，OWASP API Security Top 10 与 Web OWASP Top 10 虽然存在部分重叠（如 SSRF、认证失效），但 API 安全侧重于自动化攻击防护、细粒度授权、数据暴露控制和 API 生命周期管理，这是由 API 的技术特性决定的。

API 安全排查清单

以下排查清单可作为 API 安全评估和安全开发的参考依据：

编号	检查项	对应风险	检查方法	优先级
1	每个 API 端点是否实施了对象级授权检查？	API1: BOLA	代码审计 + 渗透测试	极高
2	自增 ID 是否替换为不可预测的标识符？	API1: BOLA	代码审计	高
3	API 是否实施了速率限制和暴力破解防护？	API2	配置审查 + 功能测试	极高
4	密码策略是否符合安全标准？	API2	配置审查	高
5	是否强制或支持多因素认证（MFA）？	API2	功能测试	中
6	JWT 令牌是否设置了合理的过期时间？	API2	代码审计	高
7	API 响应是否只返回必要的属性字段？	API3	代码审计 + 响应检查	高
8	更新操作是否使用了属性白名单机制？	API3	代码审计	极高
9	分页参数是否设置了硬上限？	API4	配置审查 + 功能测试	高
10	API 请求体最大大小是否受限制？	API4	配置审查	高
11	GraphQL 查询深度和复杂度是否受限？	API4	配置审查	中
12	管理端点是否执行了角色/权限检查？	API5	代码审计 + 渗透测试	极高
13	是否有统一的权限控制中间件/框架？	API5	代码审计	高
14	是否识别并保护了敏感业务流（如防爬虫）？	API6	架构评审 + 日志分析	高
15	敏感业务流是否实施了行为分析和异常检测？	API6	架构评审	中
16	对外部 URL 请求是否实施了白名单和协议限制？	API7: SSRF	代码审计	极高
17	是否禁止访问内部 IP 段和云元数据端点？	API7: SSRF	代码审计 + 渗透测试	极高
18	生产环境是否关闭了调试模式和错误堆栈信息？	API8	配置审查 + 功能测试	高
19	CORS 配置是否遵循最小权限原则？	API8	配置审查	高
20	是否启用了 HTTPS 和安全响应头？	API8	配置审查 + 自动化扫描	高
21	是否建立了完整的 API 资产清单？	API9	资产管理审查	高
22	是否已下线废弃的 API 版本？	API9	API 网关审查 + 端口扫描	高
23	测试/预发布环境是否与生产环境隔离？	API9	网络架构审查	高
24	对外部 API 的调用是否使用 HTTPS 并验证证书？	API10	代码审计	高
25	API 密钥和令牌是否使用秘密管理工具存储？	API10	代码审计 + 配置审查	高
26	是否对外部 API 响应数据进行了校验和过滤？	API10	代码审计	中
27	是否实施了熔断和超时机制保护下游依赖？	API10	代码审计 + 架构评审	中
28	是否具备 API 安全监控和日志审计能力？	通用	架构评审 + 日志系统检查	高
29	是否定期进行 API 安全扫描和渗透测试？	通用	安全流程审查	高
30	是否对 API 开发团队进行安全培训？	通用	安全流程审查	中

总结

OWASP API Security Top 10 2023 为 API 安全提供了系统化的风险分类和应对指南。与传统的 Web 应用安全相比，API 安全具有以下显著特点：

授权为王：三个授权相关风险（API1、API3、API5）位列前十，且 API1 稳居首位。细粒度的授权检查是 API 安全的第一道防线。
自动化攻击防护：API 天生服务于机器对机器的通信，因此需要更主动地防范自动化滥用（API4、API6）。
生命周期管理：随着 API 数量爆炸式增长，库存管理（API9）和 API 使用安全（API10）成为新焦点。
纵深防御：没有任何单一的安全措施可以防御所有风险，需要在设计、编码、部署和运维的每个环节嵌入安全控制。

建议安全团队和开发团队以本文的排查清单为基础，结合自身业务场景，建立持续的 API 安全评估和改进机制。

OWASP API Security Top 10 ​

概述 ​

API1:2023 — 对象级授权失效（Broken Object Level Authorization） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API2:2023 — 用户身份认证失效（Broken User Authentication） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API3:2023 — 对象属性级授权失效（Broken Object Property Level Authorization） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API4:2023 — 资源消耗无限制（Unrestricted Resource Consumption） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API5:2023 — 功能级授权失效（Broken Function Level Authorization） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API6:2023 — 对批量数据的不安全访问（Unrestricted Access to Sensitive Business Flows） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API7:2023 — 服务端请求伪造（Server Side Request Forgery） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API8:2023 — 安全配置错误（Security Misconfiguration） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API9:2023 — 库存管理不当（Improper Inventory Management） ​

风险描述 ​

攻击示例 ​

防御方案 ​

API10:2023 — 不安全地使用API（Unsafe Consumption of APIs） ​

风险描述 ​

攻击示例 ​

防御方案 ​

与 Web OWASP Top 10 的差异对比 ​

API 安全排查清单 ​

总结 ​

OWASP API Security Top 10

概述

API1:2023 — 对象级授权失效（Broken Object Level Authorization）

风险描述

攻击示例

防御方案

API2:2023 — 用户身份认证失效（Broken User Authentication）

风险描述

攻击示例

防御方案

API3:2023 — 对象属性级授权失效（Broken Object Property Level Authorization）

风险描述

攻击示例

防御方案

API4:2023 — 资源消耗无限制（Unrestricted Resource Consumption）

风险描述

攻击示例

防御方案

API5:2023 — 功能级授权失效（Broken Function Level Authorization）

风险描述

攻击示例

防御方案

API6:2023 — 对批量数据的不安全访问（Unrestricted Access to Sensitive Business Flows）

风险描述

攻击示例

防御方案

API7:2023 — 服务端请求伪造（Server Side Request Forgery）

风险描述

攻击示例

防御方案

API8:2023 — 安全配置错误（Security Misconfiguration）

风险描述

攻击示例

防御方案

API9:2023 — 库存管理不当（Improper Inventory Management）

风险描述

攻击示例

防御方案

API10:2023 — 不安全地使用API（Unsafe Consumption of APIs）

风险描述

攻击示例

防御方案

与 Web OWASP Top 10 的差异对比

API 安全排查清单

总结