Authorization Testing
Application-level authorization methodology - horizontal, vertical, and tenant boundary...
Install
npx skills add xalgorix/xalgorix --skill authorization-testing -g -a claude-code -y- Repository
- xalgorix/xalgorix1.3k
- Category
- Testing
- Updated
- 5d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 1,786 tokens
- Runs scripts
- No, instructions only
What it does
Application-level authorization methodology - horizontal, vertical, and tenant boundary testing, ownership transitions, method and route differentials. Replay legitimate privileged requests with lower privilege using authz_matrix first to produce differential evidence.
Authorization Testing
Purpose
Test whether the application enforces WHO may do WHAT to WHICH object - at every boundary: same-level users (horizontal), privilege levels (vertical), tenants (organizational), and lifecycle states (ownership transitions). This is the methodology layer: it decides which pairs to replay and what counts as proof.
Entry Conditions
- Any object-id parameter (/api/orders/1042), tenant header, or role-differentiated route is observed
- You hold accounts at two or more privilege levels, or two accounts in different tenants
Core Strategy: Replay the Legitimate Request, Change Only the Identity
- Perform the operation legitimately as the owner/rightful role (capture the exact request) - this is the baseline
- Replay the identical request with a lower-privilege or different-identity context
- Compare: status AND body AND effect on the object
- authz_matrix FIRST: authz_matrix url=<resource> replays your request as the second configured account and as anonymous, then records the cross-identity access differential as exploit-proven ledger evidence. Do not hand-roll multi-account curl comparisons when authz_matrix settles it in one call.
Boundary Classes
Horizontal (user -> other user objects)
- A requests B objects across every resource type: profile, orders, messages, documents, settings, payment methods
- Both directions (A->B and B->A); write operations (PUT/DELETE), not just reads
- Confirm the returned data genuinely belongs to the other principal (match IDs/names/emails) - not a benign echo
