api-security-testing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Security-test an API

对API进行安全测试

APIs fail differently from web UIs: there is no rendered surface to crawl, the interesting bugs are authorization-shaped rather than injection-shaped, and the same endpoint behaves differently per token. This workflow targets those specifics with Strix's autonomous agents, using the current OWASP API Security Top 10 (2023) as the coverage checklist. For the web-app equivalent, the current edition is the OWASP Top 10:2025 — see owasp-top-10-testing.
Install, LLM setup, full CLI flags, and the managed-cloud path are in the penetration-testing-with-strix skill. Read it if
strix --version
fails or the target is not an API.
API的故障模式与Web UI不同:没有可爬取的渲染界面,关键漏洞多为授权类而非注入类,且同一端点在不同令牌下表现不同。本工作流借助Strix的自治代理针对这些特性展开测试,以当前的OWASP API安全Top 10(2023)作为覆盖 checklist。对应的Web应用测试可参考OWASP Top 10:2025,详见owasp-top-10-testing
安装步骤、LLM配置、完整CLI参数以及托管云方案请查看penetration-testing-with-strix技能。若
strix --version
执行失败或测试目标并非API,请阅读该技能文档。

1. Gather what the agents need

1. 收集代理所需信息

APIs are near-impossible to test blind, so collect first:
InputWhy it matters
Schema — OpenAPI/Swagger file, Postman collection, GraphQL endpoint (introspection), or a gRPC
.proto
Turns guesswork into full endpoint enumeration. Biggest single win in coverage. An OpenAPI/Swagger or Postman spec (
.json
/
.yaml
/
.yml
) is a target Strix takes directly; a
.proto
is not, so pass it with
--workspace-file
.
Two sets of credentials/tokens, ideally in different tenantsBOLA/IDOR — API1:2023, still the #1 API risk — can only be proven by accessing tenant A's objects with tenant B's token.
A low-privilege and a high-privilege tokenRequired to prove broken function-level authorization (API5:2023 — a
user
calling admin-only routes).
Example object IDsLets agents test ID tampering immediately instead of hunting for valid identifiers.
Out-of-scope routesPayments, mass notification, destructive admin endpoints.
Rate limits / WAF in front of the APIAvoids agents burning budget on throttled requests; mention them so testing adapts.
Ask the user for anything missing — do not fabricate tokens or scan an API they do not own.
盲目测试API几乎不可能,因此需先收集以下信息:
输入内容重要性说明
Schema — 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 — 普通用户调用仅管理员可访问的路由)。
示例对象ID让代理可立即测试ID篡改,无需先寻找有效标识符。
非测试范围路由如支付、批量通知、破坏性管理员端点等。
API前端的速率限制/WAF避免代理因请求被限流而浪费测试资源;告知相关信息可让测试策略做出适配。
向用户索要缺失的信息——切勿伪造令牌或扫描用户不拥有的API。

2. Run the scan

2. 运行扫描

Pass the spec as a target, not as prose in the instruction — Strix parses OpenAPI/Swagger (
.json
/
.yaml
) and Postman collection exports directly, so the agents start from the real endpoint list:
bash
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 instead of OpenAPI: a collection export works as a target (
    -t ./collection.postman_collection.json
    ), or pull one live with
    -t postman://<collection-uuid>
    (optionally
    "postman://<collection-uuid>?env=<environment-uuid>"
    ), which needs
    POSTMAN_API_KEY
    in the environment.
  • Many services at once: put one target per line in a file and pass
    --target-list ./targets.txt
    , repeatable and combinable with
    -t
    .
  • Add the backend source for depth:
    -t ./services/api -t https://api.staging.example.com
    . With code access the agents can reason about authorization checks and object ownership rather than inferring them from responses.
  • gRPC: target the endpoint and pass the definition as a workspace file,
    -t https://grpc.staging.example.com --workspace-file ./service.proto
    . Only
    .json
    ,
    .yaml
    , and
    .yml
    specs are recognized as targets, so
    -t ./service.proto
    fails with "Path exists but is not a directory".
  • GraphQL: point at the GraphQL endpoint and say whether introspection is enabled; call out that you want batching/aliasing abuse, depth/complexity limits, and per-field authorization tested.
  • Internal/private APIs unreachable from your machine: use the managed platform's network connector — see managed-pentesting-with-strix.
  • Use
    --instruction-file
    when the credential/context block gets long, and keep tokens out of shell history and out of committed files.
  • Supporting files the agents should read but not test, such as an endpoint wordlist or handwritten notes about the tenancy model: pass
    --workspace-file ./notes.md
    . The file lands read-only in
    /workspace
    . Add
    :DEST
    to choose the path, for example
    --workspace-file ./wordlist.txt:lists/wordlist.txt
    .
将规范文件作为目标传入,而非以自然语言描述——Strix可直接解析OpenAPI/Swagger(
.json
/
.yaml
)和Postman集合导出文件,代理将从真实端点列表开始测试:
bash
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
    。若拥有代码访问权限,代理可直接分析授权检查逻辑和对象所有权,而非从响应中推断。
  • gRPC测试:指定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历史记录或已提交的文件中。
  • 代理需读取但无需测试的辅助文件:如端点词表或关于租户模型的手写笔记,可通过
    --workspace-file ./notes.md
    传入。文件会以只读模式存入
    /workspace
    目录。可添加
    :DEST
    指定路径,例如
    --workspace-file ./wordlist.txt:lists/wordlist.txt

3. Verify findings

3. 验证发现结果

strix_runs/<run>/penetration_test_report.md
first, then
vulnerabilities/*.md
— each contains the exact request that proved the issue. Replay it (for example, with
curl
) before reporting; for authorization findings, confirm the response really contains the other tenant's data rather than an empty 200.
findings.sarif
uploads to GitHub code scanning;
vulnerabilities.json
is the structured index for ticketing.
首先查看
strix_runs/<run>/penetration_test_report.md
,然后查看
vulnerabilities/*.md
——每个文件都包含验证问题的精确请求。在报告前需重放请求(例如使用
curl
);对于授权类发现,需确认响应确实包含其他租户的数据,而非空的200状态码。
findings.sarif
文件可上传至GitHub代码扫描;
vulnerabilities.json
是用于工单系统的结构化索引文件。

4. Fix, re-test, and keep it tested

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

Remediate with fix-security-vulnerabilities-with-strix (fix the authorization check, not the single endpoint), then re-run against the same target to prove the exploit is dead. Wire it into pull-request CI with ci-security-scanning-with-strix so new endpoints get tested as they ship.
借助fix-security-vulnerabilities-with-strix修复漏洞(修复授权检查逻辑,而非仅针对单个端点),然后针对同一目标重新运行扫描以验证漏洞已被修复。通过ci-security-scanning-with-strix将测试集成到拉取请求CI流程中,确保新端点在发布时自动完成测试。