Multi-Tenant Data Isolation Enforced

Multi-tenant applications that derive the active tenant ID from a client-supplied header, query parameter, or request body — rather than from the authenticated session — allow any authenticated user to access any organization's data by supplying that org's ID. CWE-284 (Improper Access Control) and CWE-639 (Authorization Bypass Through User-Controlled Key) both apply. OWASP A01 (Broken Access Control) lists tenant isolation failures as a primary risk. NIST 800-53 AC-3 and SC-4 (Information in Shared Resources) require that tenant boundaries be enforced by the system, not honored on trust from the client.

Derive the active tenant from the authenticated session — never from a user-supplied request parameter. If users can belong to multiple orgs, store the active org selection server-side.

// Safe — tenant from session
const orgId = session.user.activeOrgId;

// Also safe — user supplies org ID but membership is verified first
const requestedOrgId = params.orgId;
const membership = await db.orgMember.findFirst({
  where: { orgId: requestedOrgId, userId: session.user.id },
});
if (!membership) return NextResponse.json({ error: 'Not found' }, { status: 404 });

// Never do this without membership verification:
// const orgId = req.headers.get('x-org-id');

For org-switching flows, validate the switch on the server and update session.user.activeOrgId — do not let the client instruct the server which org to use by header.