API 安全测试：保护您的 API 免受漏洞威胁 | API 101 专栏 | 支流科技

关键要点

OWASP API 安全 Top 10 是基线：OWASP API Security Top 10 列举了最关键、最常被利用的 API 漏洞类别。每个安全测试项目都应将验证这份清单作为最低基线。
自动化 + 手动测试缺一不可：OWASP ZAP、Burp Suite 等自动化扫描器能快速发现已知漏洞模式，但手动渗透测试对于扫描器无法识别的逻辑缺陷和业务上下文漏洞至关重要。
安全左移：将安全测试集成到 CI/CD 流水线中，将安全从发布前的关卡转变为持续实践，显著降低修复成本。
API 网关作为防御层：部署带有安全插件的 API 网关——限流、JWT 验证、IP 白名单——在请求到达后端服务前提供强化的边界防护，有效减小攻击面。

什么是 API 安全测试？

API 安全测试是对 API 进行系统性评估，以发现攻击者可能利用的漏洞、错误配置和设计缺陷的实践。与专注于浏览器渲染界面的传统 Web 应用安全测试不同，API 安全测试针对的是程序化接口——支撑现代应用的端点、认证机制、授权逻辑和数据处理。

API 已成为主要攻击目标。根据 Gartner 的研究，API 现在是企业应用最频繁的攻击向量。原因是结构性的：API 直接暴露业务逻辑和数据，安全审查往往不如面向用户的界面严格。一个配置错误的端点可能暴露整个客户数据库；一个有缺陷的授权检查可能允许任意用户访问其他用户的数据。

安全测试通过以攻击者的思维探测 API——在真实攻击者发现之前找到弱点——来解决这一问题。

为什么 API 安全测试不可或缺

OWASP API 安全 Top 10

开放 Web 应用安全项目（OWASP）维护着 API Security Top 10，这是一份按严重程度排列的最关键 API 漏洞类别清单。理解这份清单对任何安全测试项目都至关重要：

1flowchart TD
2    A1[API1: 对象级授权失效\nBOLA / IDOR] --> A2[API2: 认证失效]
3    A2 --> A3[API3: 对象属性级授权失效]
4    A3 --> A4[API4: 资源消耗无限制]
5    A4 --> A5[API5: 功能级授权失效]
6    A5 --> A6[API6: 敏感业务流程访问不受限]
7    A6 --> A7[API7: 服务端请求伪造]
8    A7 --> A8[API8: 安全配置错误]
9    A8 --> A9[API9: 不当的资产管理]
10    A9 --> A10[API10: 不安全地使用 API]
11
12    style A1 fill:#ffebee,stroke:#c62828
13    style A2 fill:#ffebee,stroke:#c62828
14    style A3 fill:#fff3e0,stroke:#f57c00
15    style A4 fill:#fff3e0,stroke:#f57c00
16    style A5 fill:#fff3e0,stroke:#f57c00

前三项尤其值得关注：

API1：对象级授权失效（BOLA）——也称为不安全的直接对象引用（IDOR），是最普遍的 API 漏洞。当 API 端点接受资源标识符（如 /api/orders/1234）而不验证请求用户是否有权访问该特定资源时，就会发生此类问题。攻击者只需遍历 ID 即可访问其他用户的数据。

API2：认证失效——弱认证机制、缺少令牌过期时间、不安全的令牌存储，或在查询参数中接受令牌（在日志中可见）均属于此类别。暴露认证缺陷的 API 无需任何应用逻辑利用即可被攻破。

API4：资源消耗无限制——没有合理限流的 API 容易遭受滥用：大量请求降低合法用户的服务质量，或资源耗尽攻击导致后端服务崩溃。

真实世界的影响

高知名度的 API 泄露事件说明了风险的大小。2019 年，Facebook 因 API 端点缺少对用户数据查询的适当授权检查而暴露了数百万用户记录。2022 年，Twitter 的 API 漏洞允许攻击者将电子邮件地址和电话号码与用户账户关联，波及 540 万用户。这些都不是复杂的攻击——它们利用的是基本的授权和认证失效。

如何进行 API 安全测试

阶段一：侦察与资产梳理

测试前，先枚举 API 接口面：

收集 API 规范：收集 OpenAPI/Swagger 文档、Postman 集合或流量录制。
识别所有端点：使用 Postman 或 Burp Suite 的爬虫功能，发现官方文档中未列出的端点。
梳理认证方式：识别哪些端点需要认证、使用何种令牌类型（JWT、API 密钥、OAuth），以及凭证在何处传输。
映射授权边界：明确哪些角色和用户应该访问哪些资源。

阶段二：自动化扫描

自动化扫描器能快速、广泛地覆盖已知漏洞模式：

工具	类型	最适用场景
OWASP ZAP	DAST 扫描器	全面 API 扫描、CI 集成，免费
Burp Suite Pro	DAST + 手动	深度手动测试、拦截代理
42Crunch API Security Audit	静态 + DAST	OpenAPI 规范分析 + 运行时测试
Trivy	SBOM + 配置	容器和依赖漏洞
Spectral	静态（规范校验）	OpenAPI 安全规则验证

针对 OpenAPI 规范使用 OWASP ZAP 进行自动化扫描：

1# 针对 OpenAPI 规范运行 OWASP ZAP API 扫描
2docker run -v $(pwd):/zap/wrk/:rw \
3  ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
4  -t /zap/wrk/openapi.yaml \
5  -f openapi \
6  -r /zap/wrk/zap-report.html \
7  -J /zap/wrk/zap-report.json

将此集成到 CI 流水线中，自动捕获回归：

1# GitHub Actions 安全扫描作业
2security-scan:
3  runs-on: ubuntu-latest
4  steps:
5    - uses: actions/checkout@v4
6    - name: ZAP API 扫描
7      uses: zaproxy/action-api-scan@v0.7.0
8      with:
9        target: 'https://staging.example.com/api/openapi.yaml'
10        format: openapi
11        fail_action: true
12        rules_file_name: '.zap/rules.tsv'

阶段三：手动渗透测试

自动化工具会遗漏感知上下文的漏洞。手动测试的重点：

测试 BOLA/IDOR：

1# 以用户 A（ID: 100）的身份认证，尝试访问用户 B 的资源
2GET /api/v1/users/101/profile HTTP/1.1
3Authorization: Bearer <user_A_token>
4
5# 预期：403 Forbidden
6# 存在漏洞的响应：200 OK 并返回用户 B 的数据

测试功能级授权失效：

1# 以普通用户身份认证，尝试执行管理员操作
2DELETE /api/v1/admin/users/101 HTTP/1.1
3Authorization: Bearer <regular_user_token>
4
5# 预期：403 Forbidden
6# 存在漏洞的响应：200 OK 或 204 No Content

测试批量赋值：

1# 尝试通过 API 设置特权字段
2PATCH /api/v1/users/100 HTTP/1.1
3Content-Type: application/json
4Authorization: Bearer <user_token>
5
6{
7  "email": "new@example.com",
8  "role": "admin",        # 应被拒绝
9  "isVerified": true      # 应被拒绝
10}

1sequenceDiagram
2    participant 测试者
3    participant API
4    participant DB
5
6    Note over 测试者,DB: BOLA 测试场景
7
8    测试者->>API: GET /orders/1001（Auth: 用户 A 令牌）
9    API->>DB: SELECT * FROM orders WHERE id=1001
10    DB-->>API: 订单属于用户 B
11    API-->>测试者: ❌ 200 OK + 用户 B 的订单数据（存在漏洞）
12
13    Note over 测试者,DB: 安全行为
14
15    测试者->>API: GET /orders/1001（Auth: 用户 A 令牌）
16    API->>DB: SELECT * FROM orders WHERE id=1001 AND user_id=A
17    DB-->>API: 无数据（授权检查）
18    API-->>测试者: ✅ 403 Forbidden

阶段四：认证与令牌测试

JWT 验证：验证 API 拒绝 "alg": "none" 的令牌、过期令牌、有效载荷被篡改的令牌，以及使用弱密钥签名的令牌。
令牌作用域强制执行：验证具有有限作用域的访问令牌无法访问需要更大权限的端点。
API 密钥暴露：检查 API 密钥是否未被记录到日志、未在响应体中返回，以及未在 URL 查询参数中接受（在服务器日志和浏览器历史记录中可见）。
刷新令牌轮换：验证刷新令牌在使用后被撤销，以及令牌吊销机制工作正常。

阶段五：限流与资源消耗测试

测试您的限流和资源约束是否得到执行：

1# 使用简单循环测试限流
2for i in {1..200}; do
3  curl -s -o /dev/null -w "%{http_code}\n" \
4    -H "Authorization: Bearer $TOKEN" \
5    https://api.example.com/v1/search?q=test
6done
7# 超过限流阈值后应看到 429 响应

同时测试"高代价"查询：API 是否对响应大小、分页深度或嵌套查询复杂度施加了限制？

阶段六：API 网关安全验证

如果您的 API 由 Apache APISIX 或 API7 Enterprise 等网关前置，验证安全插件是否正确配置：

JWT 插件：确认无效令牌在网关处被拒绝，而非传递给上游服务。
限流插件：验证限流按消费者维度生效，而非全局生效。
IP 限制插件：确认白名单/黑名单 IP 规则得到执行。
请求验证插件：测试格式错误的请求（无效 JSON、缺少必需字段）在到达上游服务前被拒绝。

通过网关而非直接对上游服务进行测试，可以验证整个安全技术栈。

构建持续的 API 安全实践

安全测试不应是发布前的一次性活动，而应持续进行：

CI 中的静态分析：在每次 OpenAPI 规范变更时使用安全规则运行 Spectral。
预发环境中的 DAST：对每次预发环境部署运行 OWASP ZAP 扫描。
定期渗透测试：至少每年进行一次手动渗透测试，并在重大功能发布后重复执行。
依赖扫描：API 依赖于有已知 CVE 的库。在每次构建时使用 Trivy 或 Snyk 等工具扫描依赖项。
漏洞奖励计划：对于公开 API，考虑设立漏洞奖励计划，借助外部安全研究人员的力量。

结论

在 API 成为现代应用主要攻击面的威胁形势下，API 安全测试不是可选项。OWASP API Security Top 10 提供了一个清晰、可操作的测试框架。将自动化扫描与手动渗透测试相结合，既覆盖了已知模式，又能发现逻辑层面的漏洞。

最有效的安全项目将测试视为集成到开发工作流中的持续实践——在漏洞引入时就捕获，而非在数月后的安全审计中才发现。结合经过良好配置的 API 网关在边界层强制执行认证、限流和请求验证，构建纵深防御：多层安全防护要求攻击者逐层突破，而非只是一道一旦被攻破便全面暴露的单一防线。