Many multi-tenant APIs accept X-Tenant-Id, org_id, or a similar field from the client and then scope queries to that value. Trusting the client's chosen tenant is not authorization.
An authenticated user can send any tenant id they like. If you load data for that id without proving the subject is a member (or otherwise related) to that tenant, you have an IDOR with a friendlier header name. The JWT being valid only proves identity, not which orgs they may act in.
Resolve tenancy from a server-side membership or relationship check for the authenticated subject, then authorize the action inside that tenant. Treat a client-supplied tenant hint as an untrusted input: ignore it, or verify it matches a membership you already know is allowed.
Subject + action + tenant still has to win at the moment of access. A header is not a policy.
Top comments (1)
ngl saw this exact pattern in a laravel multi-tenant app. front sent tenant_id in the json, backend just trusted it. one forged request later… never again