A valid login does not prove that the user may edit this record. Authorization Testing checks each permission decision against the subject, resource, action, context, and policy that govern it.
Define the decision tuple
Start with the actual policy source and identify the subject role, resource owner, tenant, action, sensitive fields, request context, delegation, and policy version. A role name alone is not evidence that a user can access every object of that type.
| Decision dimension | Example question |
|---|---|
| Subject | Which user, service account, or delegated actor makes the request? |
| Resource | Who owns the record, and which tenant or state contains it? |
| Action | Is the request reading, editing, exporting, approving, or deleting? |
| Context | Does approval state, delegation scope, or a policy version change the result? |
| Policy and delegation | Which rule and version apply? Is the grant expired, revoked, or outside its delegation scope? |
Keep the result as allow, deny, or unknown for each supplied rule. Do not fill an unknown cell with an assumed default.
Authorization Testing: vary one permission boundary at a time
Build comparison cases that change one dimension while holding the others steady:
- Keep the subject and action, then change resource owner or tenant to expose horizontal access.
- Keep the resource and action, then change privilege level to expose vertical access.
- Keep the subject and resource, then change the action or record state.
- Revoke a delegation and compare decisions from existing sessions or caches against the documented propagation window.
Trace both permitted and denied requests to server-side enforcement and resulting data changes. A hidden button, successful login, or client-supplied tenant field does not prove an authorization decision. For denials, check that the request created no prohibited state change or side effect.
Worked example: editing a forecast
Suppose the supplied rule says a project manager may edit their team’s draft forecast but may not change another department’s approved forecast. Compare those two subject-resource-action cells, then record which policy rule and server-side evidence support each expected outcome.
If the requirement says nothing about archived forecasts or a recently revoked delegate, keep those cells unknown and ask for the governing rule. Do not turn a plausible security expectation into a confirmed vulnerability or a passing result.
The comparison becomes clearer in a subject × resource × action matrix. This illustrative table follows only the rules above; no request has been sent:
| Subject | Resource and action | Rule state | Evidence to retain |
|---|---|---|---|
| Project manager | Edit a draft forecast for their own team | Allowed by the supplied rule | Policy version, server-side decision, saved data state |
| Project manager | Edit another department’s approved forecast | Denied by the supplied rule | Policy version, denial decision, no prohibited data change or side effect |
| Project manager | Edit an archived forecast for their own team | Unknown | Ask the product or policy owner for the archive-state rule |
For a candidate validation, keep the subject and action fixed and change only the resource. An authorized tester should check the server-side decision and side effects in an isolated environment. Interpret HTTP status, UI controls, and client-supplied tenant fields under the project contract; none is authorization evidence by itself. This Skill reviews supplied material and proposes validation; it does not execute requests.
Record an AZT-## finding
For each gap, name the subject, resource, action, context, source rule, trigger, evidence state, expected concern, impact and priority, owner role, close condition, and isolated validation method. Include the denied-request side effects and any revocation timeline that affect the decision.
A validation proposal should use redacted data and an authorized isolated environment. This Skill reviews supplied policy and evidence; it does not log into a real system, call live APIs, or read credentials.
Related Skills
- Authentication Testing: https://inaodeng.com/en/qaskills/authentication-testing/ checks how identity is established.
- API Security Testing: https://inaodeng.com/en/qaskills/api-security-testing/ reviews broader API security controls.
- Security Testing: https://inaodeng.com/en/qaskills/security-testing/ helps frame the wider security scope.
Install and invoke
Install the English Skill with the Agent Skills CLI:
npx skills add naodeng/awesome-qa-skills --skill authorization-testingInstallation and troubleshooting guides:
- README: https://github.com/naodeng/awesome-qa-skills/blob/main/README_EN.md
- FAQ: https://github.com/naodeng/awesome-qa-skills/blob/main/FAQ_EN.md
- Installation guide: https://github.com/naodeng/awesome-qa-skills/blob/main/scripts/INSTALL_SKILLS_EN.md
In a tool that discovers Agent Skills automatically, describe the task directly. If the tool supports explicit invocation, use its syntax to select authorization-testing. Provide the policy source and version, subjects, resources, actions, tenant and ownership rules, revocation context, and available denial or audit evidence.
For example:
Use authorization-testing to review the following access-control policy.
Policy source and version: [fill in]
Subjects and roles: [fill in]
Resources, tenant, ownership, and state: [fill in]
Actions and applicable context: [fill in]
Existing server decisions and audit evidence: [attach material]
Unknown rules: [list them; do not fill them with assumed behavior]
Return a subject × resource × action matrix, allow/deny/unknown states, evidence gaps, and isolated validation proposals. Do not log into a real system or call a live API.FAQ
- Does a role name prove that a user can access a resource? No. Expected decisions must trace to the applicable policy, resource scope, and server-side evidence.
- Will this Skill call APIs or confirm a vulnerability? No. It reviews supplied policy and evidence and proposes candidate validation. An authorized tester must perform any actual run in an isolated environment.
- What if the policy does not define a state? Mark the combination unknown and ask the product or policy owner to confirm it. Do not fill it with an assumed allow or deny rule.
Source
Read the Authorization Testing prompt: https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/authorization-testing/prompts/authorization-testing.md before use. It defines the AZT-## finding contract and the subject/resource/action matrix with revocation timelines.