MSP trap: treating tenant ID as proof of access

MSP trap: treating tenant ID as proof of access

In multi-tenant MSP platforms, a client-supplied tenant ID is a selector (which customer context to open) — not proof that the caller may enter that context. Membership and authorization must be re-verified server-side on API calls, data reads/writes, admin actions, and async jobs.

Cite: OWASP Multi-Tenant Security Cheat Sheet. Secondary ops context: CIAOPS on GDAP/Lighthouse for SMB MSP access patterns.

OWASP checklist paraphrase (defensive, no exploit steps): bind every request to an authenticated principal; resolve tenant membership from server state, not from a client-only header; enforce object-level checks inside the tenant; separate admin/break-glass paths; log cross-tenant denials. This draft does not describe attack reproduction.

# Defensive checklist (pseudocode comments ONLY — not runnable attack code)
# 1) Authenticate caller → principal_id
# 2) Load memberships(principal_id) from server store
# 3) If requested_tenant_id NOT IN memberships → deny + audit
# 4) For each object access: assert object.tenant_id == active_tenant
# 5) Never treat X-Tenant-Id alone as authorization proof
# 6) Re-check on async workers using the same membership source

Soft land: Auris default posture is one tenant per customer; tenant ID selects the customer boundary, while soft orgs live inside that tenant. Authorization remains a server-side membership check — not a client field.

Draft only — do not publish without editorial review.