api-security-testing

对 API 进行安全测试

API 的失效方式与 Web UI 不同：没有可供爬取的渲染界面，有趣的漏洞更多与授权有关，而非注入；同一个端点在不同令牌下的行为也会有所不同。此工作流使用 Strix 的自主 Agent 针对这些特点进行测试，并以当前的 OWASP API Security Top 10（2023） 作为覆盖清单。对于对应的 Web 应用测试，请参阅当前版本 OWASP Top 10:2025 中的 owasp-top-10-testing。

安装、LLM 设置、完整 CLI 标志和托管云端方案详见 penetration-testing-with-strix 技能。如果 strix --version 运行失败，或目标不是 API，请阅读该技能。若要在没有 Docker 和 LLM 密钥的情况下运行，可使用同一个二进制文件驱动托管平台：先运行 strix cloud login，再运行 strix cloud scans start ...（详情见 managed-pentesting-with-strix）。

1. 收集 Agent 所需的信息

几乎不可能在没有任何背景信息的情况下测试 API，因此请先收集以下内容：

输入	重要性
架构 — OpenAPI/Swagger 文件、Postman 集合、GraphQL 端点（内省），或 gRPC .proto 文件	将猜测变为完整的端点枚举，是提升覆盖率最有效的单项措施。Strix 可直接将 OpenAPI/Swagger 或 Postman 规范（.json/.yaml/.yml）作为目标；但 .proto 不行，因此请通过 --workspace-file 传入。
两组凭据/令牌，最好属于不同的租户	BOLA/IDOR（API1:2023）仍是排名第一的 API 风险。只有使用租户 B 的令牌访问租户 A 的对象，才能证明存在此问题。
低权限和高权限令牌	这是证明函数级授权失效所必需的（API5:2023，即 user 调用仅限管理员使用的路由）。
示例对象 ID	让 Agent 能立即测试 ID 篡改，而不必先查找有效标识符。
范围外路由	支付、批量通知、具有破坏性的管理端点。
API 前方的速率限制 / WAF	避免 Agent 将预算耗在受限请求上；请说明这些限制，以便调整测试方式。

如果有信息缺失，请向用户询问；不要编造令牌，也不要扫描用户无权测试的 API。

2. 运行扫描

将规范作为目标传入，而不是写在指令的说明文字中——Strix 可直接解析 OpenAPI/Swagger（.json/.yaml）和 Postman 集合导出文件，因此 Agent 会从真实的端点列表开始：

strix -n -t ./openapi.yaml -t https://api.staging.example.com --max-budget 20 \
  --instruction "Tenant A token: <tokenA> (org 1111, user id 11, order id 501).
Tenant B token: <tokenB> (org 2222, user id 22).
Admin token: <tokenAdmin>.
Focus: BOLA across orgs (API1), function-level authz on /admin/* (API5), object property level authz on PATCH /users/{id} — both mass assignment and over-exposed fields in list responses (API3), unrestricted resource consumption (API4).
Out of scope: POST /billing/*, POST /notifications/broadcast."

• **使用 Postman 而非 OpenAPI：**集合导出文件可作为目标（-t ./collection.postman_collection.json），也可以通过 -t postman://<collection-uuid> 获取在线集合（可选 "postman://<collection-uuid>?env=<environment-uuid>"），这需要在环境中设置 POSTMAN_API_KEY。
• **同时扫描多个服务：**在文件中每行放一个目标，然后传入 --target-list ./targets.txt；该参数可重复使用，也可与 -t 组合使用。
• 添加后端源代码以进行深入分析：-t ./services/api -t https://api.staging.example.com。如果能访问代码，Agent 就可以分析授权检查和对象所有权，而不必根据响应进行推断。
• **gRPC：**将端点作为目标，并将定义作为工作区文件传入：-t https://grpc.staging.example.com --workspace-file ./service.proto。只有 .json、.yaml 和 .yml 规范会被识别为目标，因此 -t ./service.proto 会报错："Path exists but is not a directory"。
• **GraphQL：**指定 GraphQL 端点，并说明是否启用了内省；明确要求测试批处理/别名滥用、深度/复杂度限制和字段级授权。
• **无法从你的机器访问的内部/私有 API：**使用托管平台的网络连接器——参见 managed-pentesting-with-strix。
• 当凭据/上下文部分较长时，使用 --instruction-file，并避免将令牌留在 shell 历史记录或提交的文件中。
• 供 Agent 阅读但不作为测试目标的辅助文件，例如端点词表或关于租户模型的手写笔记：传入 --workspace-file ./notes.md。Strix 会将文件复制到 /workspace。你机器上的文件不会更改。添加 :DEST 可指定路径，例如 --workspace-file ./wordlist.txt:lists/wordlist.txt。

3. 验证发现

先查看 strix_runs/<run>/penetration_test_report.md，再查看 vulnerabilities/*.md——每个文件都包含证实问题的确切请求。在报告之前重放请求（例如使用 curl）；对于授权问题，请确认响应确实包含其他租户的数据，而不是空的 200 响应。

findings.sarif 可上传到 GitHub 代码扫描；vulnerabilities.json 是用于工单处理的结构化索引。

4. 修复、重新测试并持续测试

使用 fix-security-vulnerabilities-with-strix 修复问题（修复授权检查，而不是单个端点），然后针对同一目标重新运行，以证明漏洞利用已失效。将其接入拉取请求 CI，使用 ci-security-scanning-with-strix 测试新上线的端点。