An authorization matrix for a multi-role, multi-tenant penetration test must model decisions, not merely list accounts. Each test row should identify an actor, source tenant, target resource owner, target tenant, action, object state, expected result and observed evidence. This makes horizontal, vertical, function-level and cross-tenant coverage explicit.

Build the matrix with engineering and security before testing, then let the tester refine it as new routes and relationships appear. The matrix is both a planning tool and a coverage record; it should never become a script that prevents exploration.

Inventory principals and contexts

  • Anonymous, newly registered and verified users.
  • Standard, privileged, administrative and support roles.
  • Service accounts, API clients and workload identities.
  • Delegated, impersonated, suspended and revoked identities.
  • Users with membership in multiple tenants or organizations.

Assign stable aliases to test identities. Record authentication method, role, tenant memberships and lifecycle state. Avoid using one superuser account for every positive case because it masks policy distinctions.

Inventory resource and action families

Group objects by policy and business consequence: customer records, transactions, files, configurations, memberships, credentials, exports and administrative operations. For each family, list meaningful actions such as create, list, search, read, update, delete, share, approve, transfer and export.

Map web, mobile, API, bulk and asynchronous paths to the same action where applicable. A control tested through one client may be bypassed through another implementation.

Create controlled ownership and tenant data

  1. Create two peer users in tenant A with separate owned objects.
  2. Create equivalent users and objects in tenant B.
  3. Add privileged and support identities with deliberately bounded rights.
  4. Create shared, delegated and unshared objects where the product supports them.
  5. Prepare objects in pending, approved, archived and transferred states.
  6. Record expected policy decisions before adversarial testing.

Synthetic test data should resemble real relationships without containing customer information. Restore or reseed state when destructive or one-time operations are tested.

Execute positive controls first

Confirm that the intended actor can perform the action. Positive tests establish valid state and distinguish authorization failure from broken setup. Capture the normal request, identity context and resulting state for comparison.

Run same-role peer tests

Substitute another user’s identifier, nested object, file reference, search filter or workflow token while preserving the attacker’s own credentials. Test direct access and indirect discovery. Include list, export and bulk functions that can leak many objects even when individual reads are protected.

  • Peer A reading or changing Peer B’s object.
  • Peer A enumerating Peer B’s identifiers through search or errors.
  • Peer A invoking a workflow transition on Peer B’s record.
  • Peer A accessing derived files, logs or notifications.

Run vertical and function-level tests

Use lower-privilege identities to call privileged operations directly. Remove UI assumptions and exercise the server route, API operation or background trigger. Also test whether higher roles exceed their intended administrative scope, especially across tenants.

  • Direct route access without the privileged UI.
  • Method or content-type changes against the same operation.
  • Bulk and import functions that call privileged logic indirectly.
  • Support or impersonation functions outside approved purpose.

Run cross-tenant tests

Repeat representative reads and writes using identities and objects from different tenants. Test identifiers, search, exports, caches, object storage, webhooks, queues and background jobs. Tenant context must survive every hop, not only the first request handler.

Include parent-child organizations, shared users, partner access and platform administration as separate relationships. They are legitimate exceptions that need narrow policy boundaries.

Test lifecycle transitions

  • Role changed while session and refresh token remain valid.
  • Membership revoked during a running job.
  • Object ownership transferred between users or tenants.
  • Invitation reused after acceptance or expiry.
  • Tenant disabled while API credentials remain active.

Repeat selected matrix cells before and after the transition. Cached claims and asynchronous consumers often retain stale authorization context.

Use equivalence groups without hiding gaps

Group routes only when they share the same enforcement policy, identity context and data-access path. Sample at least one sensitive read and state-changing action per group. Expand coverage when a legacy route, alternate client or bulk function bypasses the shared control.

Record the reason for sampling in the matrix. Similar endpoint names or UI screens are not evidence of equivalent enforcement.

Capture outcomes precisely

  • Allowed as expected.
  • Denied safely as expected.
  • Unexpected data disclosure or state change.
  • Ambiguous because response differs but impact is unproven.
  • Blocked by environment, data or access.
  • Not selected under the documented sampling rule.

A different status code is not automatically a successful denial. Verify response content, side effects, audit events, async processing and subsequent object state.

For a failed cell, preserve both authorized and unauthorized request-response pairs, ownership proof, before-and-after state and business impact. Link related cells that share the same root cause. For passed cells, retain enough tester notes to support the coverage claim without storing unnecessary sensitive traffic.

Reconcile at coverage checkpoints

  1. Review identities and accounts that failed.
  2. Add newly discovered roles, routes and tenant relationships.
  3. Confirm sampling assumptions still hold.
  4. Resolve ambiguous outcomes and missing state.
  5. Document deferred or prohibited tests and their impact.

Use the authorization-testing guidance in the OWASP Web Security Testing Guide as a technique source, then execute it through the product-specific matrix of principals, resources, actions and tenants.

Turn the matrix into lasting coverage

Convert the most important positive and negative cells into regression tests. Update the matrix when roles, tenancy, identity providers or critical workflows change. Use future pentests to challenge both the policy and the assumption that shared enforcement remains universal.

The practical decision

A defensible authorization test records the relationship behind every decision. Build representative peer, vertical, cross-tenant and lifecycle combinations; execute them across function-level and object-level paths; verify real side effects; and show the sampling logic. That is how AppSec can tell which controls were challenged and which remain unknown.

Build an authorization-led application pentest with WIMD using a concrete role, object, action and tenant coverage matrix.