← Back to Internal system builders

Skill · Version 1.0.0

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

Team members using this skill

See how it helps

When 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.

Details…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:

  1. 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 404 without leaking existence).
  2. Resource Lifecycle State Boundaries:
    • Action allowed in draft state (edit, delete) $\rightarrow$ must be denied once the resource transitions to submitted, approved, fulfilled, or locked.
  3. 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 manager or approver role!) attempts to approve their own request $\rightarrow$ must be denied.
  4. 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.
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, and export return 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 into POST/PATCH payloads.
  • 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.

Included files 1

  • SKILL.md