Check who can access what
Checks that people can only view and change what they are allowed to, including bulk actions and data exports.
authorization-verification
See how it helpsWhen is it useful?
Use this skill to check whether permissions hold in real situations, beyond a simple administrator-versus-guest test. It covers ownership, teams, record states and the ways data can escape through lists or exports.
What does it help you do?
- Builds tests for allowed and forbidden actions across roles, owners, departments and organizations.
- Checks locked records, self-approval attempts, expired access and approvals based on outdated data.
- Verifies that search results, counts, exports and individual fields follow the same access rules as detail pages.
Try asking this
Review the course permissions: learners should see only their own results and instructors only their assigned courses. Include direct URLs, exports and revoked access in the tests. Move an instructor to a different course and repeat the checks. Old links and cached counts must no longer reveal the previous learners' results.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Authorization Verification
When to Use
Use when writing tests for or reviewing any role, permission, ownership rule, field mask, delegation grant, or approval workflow.
Combinatorial Policy Test Matrix
A test that only verifies admin can perform an action and guest gets 403 leaves the actual business rules untested. Derive test cases systematically from the cartesian boundary of (Actor Role & Relationship) × (Resource State & Value) × (Operation):
1. Required Positive & Negative Test Cases
For every protected operation, assert both authorized allow and unauthorized deny across:
- Role & Ownership Boundaries:
- Resource owner vs. non-owner peer in the same department.
- Department/team manager of the owner vs. manager of a different department.
- Read-only viewer/auditor vs. active editor.
- Cross-tenant user (member of Workspace B targeting a resource in Workspace A $\rightarrow$ must return
404without leaking existence).
- Resource Lifecycle State Boundaries:
- Action allowed in
draftstate (edit,delete) $\rightarrow$ must be denied once the resource transitions tosubmitted,approved,fulfilled, orlocked.
- Action allowed in
- Threshold & Separation-of-Duties (SoD) Boundaries:
- Value just below threshold (
9,999.99) vs. at/above threshold (10,000.00). - Self-Approval Attempt: The creator/requester of a request (even if they hold a
managerorapproverrole!) attempts to approve their own request $\rightarrow$ must be denied.
- Value just below threshold (
- Tampered / Stale Approval & TOCTOU Attempts:
- Modify a critical parameter (price, discount, recipient, bank account, quantity) on a request after it was approved, or submit an approval against a stale
version/ payload hash $\rightarrow$ must invalidate the approval or reject the commit.
- Modify a critical parameter (price, discount, recipient, bank account, quantity) on a request after it was approved, or submit an approval against a stale
2. Verify Side-Channel & Collection Enforcement
- List, Search, Count & Export Parity:
- Seed 3 records: one owned by the actor, one in another department (forbidden), and one in another tenant (forbidden).
- Assert that
list,search,count/aggregate, andexportreturn only the 1 permitted record and do not leak the existence or field values of the forbidden records in error messages or facet counts.
- Field-Level Redaction & Mass-Assignment Protection:
- Assert that restricted fields (
cost_price,internal_margin,ssn,approver_notes,role,status) are omitted from JSON responses for unauthorized roles and rejected/ignored when injected intoPOST/PATCHpayloads.
- Assert that restricted fields (
- Delegation & Revocation Expiry:
- Advance the test clock past
expires_at(or revoke the grant/role) and assert that immediate subsequent calls and queued delayed actions are rejected.
- Advance the test clock past
Included files 1
SKILL.md
