Tenant context is set from authenticated session, not client input

Sourcing tenant context from client-supplied values — a request body tenantId, a query parameter, or an unverified path segment — is CWE-639 and OWASP A04 (Insecure Design) in combination: any user who can forge or swap that value gains access to an arbitrary tenant's data. This is not a theoretical risk; it is one of the most common multi-tenancy bugs because the attack requires only changing a single field in a normal API call. NIST AC-3 requires that access decisions be based on authoritative session state, not client assertions.

Resolve tenant identity exclusively from the server-side session. If a tenant ID appears in the URL (e.g., /api/orgs/:orgId/), treat it as an untrusted assertion and cross-check it against the authenticated user's memberships before using it:

// src/middleware/tenantAuth.ts
const session = await getServerSession()
if (!session) return new Response('Unauthorized', { status: 401 })

const { orgId } = params
const membership = await db.memberships.findFirst({
  where: { userId: session.user.id, organizationId: orgId }
})
if (!membership) return new Response('Forbidden', { status: 403 })

// Safe to use orgId now — membership is confirmed

Never pass tenantId from request bodies into database where clauses without this validation step. Centralize the membership check in middleware so no route can accidentally skip it.