An API pentest needs two accounts with the same role and accounts in two tenants because authorization is relational. One account proves that authentication works; it cannot prove whether an ordinary user can access another user’s object or whether a tenant boundary is enforced. Paired identities create the negative comparisons needed to detect horizontal, vertical and cross-tenant failures.

Define the architecture question before testing

Define the identity pairs from the product’s actual model: anonymous and authenticated, user and peer, user and administrator, tenant A and tenant B, active and revoked, owner and collaborator, human and machine. The matrix should reflect relationships and actions, not just role names.

Write the expected security invariant and the prohibited outcome in language that engineering, security and operations interpret the same way. Name the identity, trust transition, protected asset and authoritative state. That statement becomes the basis for scope, evidence and retesting.

Build the minimum evidence pack

  • A current component and trust-boundary diagram for the environment under test.
  • Identity, credential, network and data-flow details relevant to the decision.
  • Representative accounts, workloads and synthetic records with known ownership.
  • Logs or traces that follow the action through every material control point.
  • Explicit safety limits, stop conditions, owners and restoration steps.

Prepare dedicated users, at least two accounts per material role where horizontal access matters, at least two tenants, privileged and ordinary roles, synthetic owned objects, shared objects, revoked states and a reset procedure. Provide expected relationships without giving away where weaknesses are believed to exist.

Prove horizontal authorization with same-role peers

Two users may have identical permissions in the role model but different object ownership. Testing only one user’s own records never exercises that boundary.

  • Read, update and delete the peer’s object.
  • Use known and discovered identifiers.
  • Test nested, bulk, search and export operations.
  • Change sharing or ownership relationships.
  • Compare error, timing and side effects.

Label every canary object by owner and verify final state. A 404 or 403 is useful only when no data, mutation or delayed effect occurred.

Prove tenant isolation independently of role

A tenant administrator may be powerful inside one organization and forbidden everywhere else. Two tenants separate role authority from tenant scope.

  • Use equivalent roles in tenant A and tenant B.
  • Swap tenant, organization and object identifiers.
  • Test caches, jobs, files and reports.
  • Check shared users and invitations.
  • Exercise platform-support exceptions under explicit scope.

Track tenant context at gateway, service, database and asynchronous consumer where possible. The final store or file must remain isolated.

Test vertical boundaries with different roles

Ordinary and privileged accounts show whether function-level authorization is enforced server-side rather than hidden in the client.

  • Call privileged routes with an ordinary token.
  • Add privileged fields to allowed requests.
  • Replay administrator object identifiers.
  • Test role changes during an active session.
  • Compare alternate versions and internal routes.

Record the function, required authority and actual business effect. Menu visibility is not an authorization control.

Include lifecycle and revocation states

Authorization changes over time. A removed member, expired invite, transferred owner or revoked token can retain stale access through sessions, caches or queued work.

  • Act before and after role removal.
  • Use sessions issued before a permission change.
  • Run delayed jobs after revocation.
  • Transfer object or tenant ownership.
  • Test archived and soft-deleted records.

Capture timestamps and authoritative membership or ownership. State how quickly policy is expected to converge.

Prepare accounts without exposing customer data

Realistic relationships do not require real customer identities. Synthetic accounts and canary objects make evidence safer and clearer.

  • Use dedicated mailboxes and non-production secrets.
  • Seed distinct records for each identity and tenant.
  • Avoid shared passwords and personal accounts.
  • Give testers only the privileges the matrix requires.
  • Revoke credentials and clean up after closure.

Maintain an account register with role, tenant, owner, creation and expiry. Ensure logs can distinguish tester identities.

Turn the matrix into repeatable coverage

A useful matrix connects every high-risk action with positive and negative identity-object combinations. It makes omissions visible before and after the test.

  • List actions rather than only endpoints.
  • Map routes and channels to each action.
  • Mark tested, blocked, not applicable and residual outcomes.
  • Add findings and retest status to the same row.
  • Convert confirmed cases into integration regression.

Coverage claims should cite completed identity pairs and limitations. Account setup failure is a scope gap, not a passed control.

Retest without narrowing to one URL

After a fix, repeat the failing pair and sample all consumers of the shared policy. The account relationships are the reusable test fixture.

  • Repeat original actor-object combination.
  • Swap to the other tenant.
  • Test a sibling route and bulk path.
  • Verify allowed owner and administrator cases.
  • Inspect asynchronous and cached effects.

Closure demonstrates the invariant across the pattern and preserves legitimate access, not only a changed response on the reported endpoint.

Execute as controlled hypotheses

  1. Establish the legitimate baseline and capture authoritative state.
  2. Change one trust variable—identity, route, scope, object, time or environment.
  3. Observe the decision at each layer rather than relying only on the response.
  4. Stop at the minimum proof that demonstrates or rejects the hypothesis.
  5. Restore test state and record residual uncertainty or blocked coverage.

Use only authorized synthetic tenants and objects. Clearly identify tester traffic and avoid real customer identifiers. Keep platform-wide roles narrowly controlled, and agree whether support impersonation or break-glass paths are in scope.

Report the architectural consequence

For every authorization finding, name source identity, target identity or tenant, object relationship, action, expected decision and observed effect. Include the matrix coverage summary and any missing account combinations.

Separate observed evidence from inference. State prerequisites, repeatability, blast radius and the shared component responsible for the decision. When multiple findings have one architectural cause, keep the individual proofs but group the remediation around the common control.

Required closure evidence

  • The original proof no longer succeeds.
  • A legitimate workflow still succeeds under the intended identity and route.
  • Alternate consumers of the same pattern enforce the same invariant.
  • Telemetry records both allowed and denied decisions with useful context.
  • The architecture record and threat assumptions reflect the new control.

Remediate at the durable control point

Enforce actor, tenant, object and action at the authoritative service or data query; standardize policy helpers; expire stale sessions and jobs appropriately; and maintain reusable paired-account regression fixtures.

Retest the invariant, not just the payload

Use the same identity pairs and canary relationships, repeat the exploit, then sample sibling operations and lifecycle states. Verify legitimate owner, collaborator and administrative actions still succeed.

Use the NIST Technical Guide to Information Security Testing and Assessment for assessment planning and evidence discipline, and the OWASP Web Security Testing Guide for relevant application techniques. Adapt both to the system-specific trust decision described here.

The architecture decision

Two same-role users and two tenants are not duplicate accounts. They are the minimum experimental controls needed to prove horizontal ownership and tenant isolation. Add privileged and lifecycle identities according to the product’s risk model.

Ask WIMD to build the API identity-pair matrix and test authorization with evidence across roles, users and tenants.