Build a Tenant Authorization Matrix

A role label is too coarse to verify multi-tenant access. A member may read a project but not export it. An administrator may manage members in one organization but not inspect another organization's billing records. Write the expected decisions before implementation or testing. OWASP Authorization recommends explicit access rules, and its regression-testing guidance turns those rules into repeatable checks.

Build the decision artifact

Start with one resource family. List the principal, tenant relationship, action, and expected result. Keep the table small enough that each row can become a test.

Do not use “admin” as a wildcard. Record the exact resource and tenant for every privileged action. A public object needs its own row, because a public read does not imply public update, export, or attachment access.

Convert rows into tests

Create two synthetic tenants with different marker values. For each allowed row, assert that the requested action works and returns only the expected fields. For each denied row, assert both the response and the absence of side effects. A denial that still creates an export job is not a denial. Repeat relevant rows after role removal, organization switching, and session refresh.

Keep policy and implementation separate. The matrix says what should happen; a route test shows what happened in a specific build. Link each test to its rule and record any route that has no owner. The OWASP Authorization Regression Testing Cheat Sheet is a useful source for this mapping.

If the team cannot agree on a row, do not invent a permission rule during implementation or testing. Mark the decision pending, assign a product owner, and keep the affected action out of release until the rule is clear.