Shared Resources Have Access Controls

Shared and team resources introduce a second authorization dimension: not just "is the user authenticated?" but "is the user a member of the group that owns this resource?" Skipping the membership check (CWE-639, CWE-284) means any authenticated user who knows a team project ID can read or modify it. OWASP A01 (Broken Access Control) explicitly covers this: authorization must verify the relationship between the principal and the resource, not just that a session exists. NIST 800-53 AC-3 requires access enforcement to reflect actual entitlements — membership in the owning group is the entitlement for shared resources.

Before serving any shared resource, verify the requesting user is a member of the group that owns it. Do this as a database query, not as a client-supplied parameter.

// app/api/teams/[teamId]/projects/route.ts
const membership = await db.teamMember.findFirst({
  where: { teamId: params.teamId, userId: session.user.id },
});
if (!membership) return NextResponse.json({ error: 'Not found' }, { status: 404 });

// Membership confirmed — safe to return team data
const projects = await db.project.findMany({ where: { teamId: params.teamId } });

Separating the membership check from the data query (rather than using a join) makes the authorization step explicit and resistant to accidental removal in future refactors.