成功登录不能证明用户有权编辑这条记录。授权测试会根据主体、资源、动作、上下文和适用策略检查每项权限判断。
定义授权判断维度
先找到实际策略来源，再记录主体角色、资源所有者、租户、动作、敏感字段、请求上下文、委派关系和策略版本。角色名称本身不能证明用户可以访问该类型的所有对象。
| 判断维度 | 示例问题 |
|---|---|
| 主体 | 发起请求的是哪个用户、服务账号或受委派者？ |
| 资源 | 记录由谁拥有，属于哪个租户和状态？ |
| 动作 | 请求是在读取、编辑、导出、批准还是删除？ |
| 上下文 | 审批状态、委派范围或策略版本是否会改变结果？ |
| 策略与委派 | 适用哪条规则和哪个版本？授权是否过期、撤销或超出委派范围？ |
对每条有来源的规则记录允许、拒绝或未知；不要用未经确认的默认值补齐未知项。
授权测试：每次只改变一个权限边界
构造对照场景时，每次只改变一个维度，其他条件保持一致：
- 主体和动作不变，替换资源所有者或租户，检查水平越权边界。
- 资源和动作不变，替换权限级别，检查垂直越权边界。
- 主体和资源不变，替换动作或记录状态。
- 撤销委派后，按文档化的传播窗口比较旧会话或缓存中的决策。
许可和拒绝都要追溯到服务端权限检查及其数据变化。隐藏按钮、成功登录或客户端传入的 tenant 字段都不能证明服务端执行了授权判断。检查拒绝请求是否仍产生了禁止的数据变更或其他副作用。
示例：编辑预测数据
假设提供的规则允许项目经理编辑自己团队的草稿预测，但不允许修改其他部门已批准的预测。分别核对这两个主体 - 资源 - 动作组合，并记录支撑预期结果的策略规则和服务端证据。
如果需求没有说明已归档预测或刚撤销委派的处理方式，就把这些项标为未知并询问适用规则。不要把合理猜测写成已确认的漏洞或通过结果。
把同一组规则放进主体×资源×动作矩阵，可以直接看到已知与未知项。下表不代表已发送请求：
| 主体 | 资源与动作 | 规则状态 | 需要留存的证据 |
|---|---|---|---|
| 项目经理 | 自己团队的草稿预测 / 编辑 | 规则允许 | 策略版本、服务端授权结果、保存后的数据状态 |
| 项目经理 | 其他部门已批准的预测 / 编辑 | 规则拒绝 | 策略版本、拒绝决策、无禁止的数据变更或副作用 |
| 项目经理 | 自己团队已归档的预测 / 编辑 | 未知 | 请求产品或策略负责人确认归档状态的规则 |
候选验证可以保持主体与动作不变，只替换资源；实际运行时，由获授权的测试人员在隔离环境检查服务端决定和数据副作用。HTTP 状态码、界面按钮和客户端提交的租户字段都应按项目契约解释，不能单独当作授权证据。这个 Skill 只复核材料并提出验证建议，不会执行请求。
记录 AZT-## 发现
每个缺口都应说明主体、资源、动作、上下文、来源规则、触发条件、证据状态、预期关注点、影响与优先级、负责人角色、关闭条件和隔离验证方法。还要记录拒绝请求的副作用，以及会影响判断的撤权时间线。
验证建议应使用脱敏数据和获授权的隔离环境。这个 Skill 复核提供的策略和证据；不会登录真实系统、调用线上 API 或读取凭据。
相关 Skill
- 认证测试：https://inaodeng.com/zh-cn/qaskills/authentication-testing/；检查身份如何建立。
- API 安全测试：https://inaodeng.com/zh-cn/qaskills/api-security-testing/；复核更广的 API 安全控制。
- 安全测试：https://inaodeng.com/zh-cn/qaskills/security-testing/；用于梳理整体安全范围。
安装与调用
使用 Agent Skills CLI 安装中文版本：
npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill authorization-testing安装说明与排查方式：
- README：https://github.com/naodeng/awesome-qa-skills/blob/main/README.md
- FAQ：https://github.com/naodeng/awesome-qa-skills/blob/main/FAQ.md
- 安装手册：https://github.com/naodeng/awesome-qa-skills/blob/main/scripts/INSTALL_SKILLS.md
工具支持 Agent Skills 自动发现时，可以直接描述任务；如果工具支持显式调用，按它自己的语法指定 authorization-testing。提供策略来源与版本、主体、资源、动作、租户和所有权规则、撤权上下文，以及现有拒绝或审计证据。
例如：
请使用 authorization-testing 评审以下访问控制规则。
策略来源与版本：[填写]
主体与角色：[填写]
资源、租户、所有权和状态：[填写]
动作与适用上下文：[填写]
现有服务端决定和审计证据：[附材料]
未知规则：[列出；不要使用默认行为补齐]
请输出主体×资源×动作矩阵、允许/拒绝/未知状态、证据缺口和隔离验证建议。不要登录真实系统或调用线上 API。常见问题
- 角色名称能证明用户有访问权限吗？ 不能。预期决定必须能追溯到适用策略、资源范围和服务端证据。
- 这个 Skill 会直接测试 API 或确认漏洞吗？ 不会。它评审提供的策略和证据、提出候选验证；实际执行需要获授权的测试人员在隔离环境完成。
- 策略没有说明某个状态怎么办？ 将该组合标为未知，并请产品或策略负责人确认；不要自行补默认允许或拒绝。
源文件
使用前请阅读授权测试 Prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/authorization-testing/prompts/authorization-testing.md。其中定义了 AZT-## 发现契约、主体/资源/动作矩阵和撤权时间线。