Reject Untrusted Tenant Headers
Derive tenant context from verified membership instead of trusting a caller-supplied header.
A caller can set its own HTTP headers. X-Tenant-ID may be a useful requested context, but it is not authority. The server must verify that the authenticated caller belongs to that tenant and may act on the named resource. OWASP Authorization supports decisions from trusted identity and resource facts.
Trusted-context map
List the source of every value used in an authorization decision.
| Value | Trusted source | Check |
|---|---|---|
| User ID | Validated session or access token | Identity is current |
| Selected tenant | Membership lookup | User belongs now |
| Role | Current tenant grant | Action is allowed |
| Resource owner | Stored record | Owner matches authorized context |
| Request header | Caller input | Hint only, never independent authority |
A server may accept a selected tenant header after checking membership. That is different from treating the header as proof. If the product allows a person in multiple tenants, record how it resolves an omitted selection and how it handles an invalid one. Do not silently fall back to an all-tenant view.
Test the derivation
Use two synthetic tenants. Authenticate as A and send a request that names B in the header. Confirm denial or a safe selection error. Repeat with a missing header, stale membership, and a resource that belongs to B while the header names A. Check list, detail, write, and export routes because they may use separate middleware. Inspect response data and side effects, not only status codes.
A proxy may set identity headers too. If the origin can be reached directly, clients may forge those values. Record which ingress strips untrusted headers and which proxy may add trusted ones. OWASP Multi Tenant Security frames the isolation goal. This map shows where a requested tenant becomes an authorized tenant. Keep tests on owned or explicitly authorized systems. A UI selector is not an access control.
Also test an account that legitimately belongs to both tenants. The server may accept a selected tenant only after checking membership. The response must stay within that selected tenant; a valid multi-tenant account is not an all-tenant query by default.
Find the gaps in your access controls
See how an illustrative cross-workspace finding connects evidence, impact and a fix. Discuss the tenant boundaries your team needs reviewed.