Authorization and IDOR: "Authenticated" Is Not "Authorized"

// app/api/documents/[id]/route.ts — "secured" but not really
export async function DELETE(req: Request, { params }: { params: { id: string } }) {
  const user = await getUser(req);
  if (!user) {
    return Response.json({ error: 'Unauthorized' }, { status: 401 });
  }

  // Any logged-in user reaches this line — including the lowest-privilege role.
  // Nothing here checks that `user` owns, is assigned to, or is even allowed
  // to touch document `params.id`.
  await db.documents.delete({ where: { id: params.id } });

  return Response.json({ success: true });
}

# 1. Find every dynamic-ID route (the classic IDOR shape)
grep -rln "params\.id\|params\[.id.\]\|req\.params\.id\|:id" --include="*.ts" --include="*.tsx" app/api server/src/routes

# 2. For each one, check whether the handler does anything with the ID besides
#    an auth check before querying/mutating by that ID. Look for a SECOND
#    check — ownership, assignment, or role — after the auth check:
grep -A 20 "getUser(req)\|requireAuth" <route-file> | grep -E "owner|assign|role|can\(|permission"
# If you don't see a second check referencing the object owner/assignment,
# that route is very likely IDOR-vulnerable.

# 3. Specifically flag DELETE and PATCH handlers with only one guard clause —
#    these are the highest-impact version of the bug
grep -B5 "\.delete(\|\.destroy(\|admin\.from.*delete" --include="*.ts" -r app/api server/src/routes | grep -B5 "delete" | grep -c "getUser\|requireAuth"

# 4. Look for a cache layer keyed on an object ID without the user ID folded
#    into the key — this is the same bug one level down the stack
grep -rn "cache\.\(get\|set\)(" --include="*.ts" . | grep -v "userId\|user_id"

// lib/access-control.ts — one place, reused everywhere
export async function assertObjectAccess(
  userId: string,
  userRole: string,
  objectId: string,
  action: 'view' | 'edit' | 'delete'
): Promise<void> {
  // Elevated roles bypass the assignment check but NOT the permission check
  if (!roleCan(userRole, action)) {
    throw new ForbiddenError(`Role ${userRole} cannot ${action}`);
  }

  // Roles that are scoped to specific objects (not global admins) must have
  // an explicit assignment row — this is the check that was missing above
  if (isScopedRole(userRole)) {
    const assignment = await db.userAssignments.findFirst({
      where: { userId, objectId },
    });
    if (!assignment) {
      throw new ForbiddenError('Not assigned to this object');
    }
  }
}

// app/api/documents/[id]/route.ts — fixed
export async function DELETE(req: Request, { params }: { params: { id: string } }) {
  const user = await getUser(req);
  if (!user) return Response.json({ error: 'Unauthorized' }, { status: 401 });

  try {
    await assertObjectAccess(user.id, user.role, params.id, 'delete');
  } catch (e) {
    return Response.json({ error: 'Forbidden' }, { status: 403 });
  }

  await db.documents.delete({ where: { id: params.id } });
  return Response.json({ success: true });
}

// Broken: cache key doesn't include userId, and the ownership check
// only runs on a cache MISS — a cache HIT skips authorization entirely
const cached = await redis.get(`thumbnail:${videoId}`);
if (cached) return cached; // <-- returns another user's signed URL if they share a videoId

// Fixed: scope the key to the requester, and check ownership before any cache read
async function getThumbnail(userId: string, videoId: string) {
  await assertObjectAccess(userId, role, videoId, 'view'); // check FIRST
  const cacheKey = `thumbnail:${userId}:${videoId}`;
  const cached = await redis.get(cacheKey);
  if (cached) return cached;
  // ...generate, cache under the scoped key, return
}

Audit this repository for IDOR (Insecure Direct Object Reference) and missing
object-level authorization.

For every API route that accepts an object ID (a URL path param like [id] or
:id, or an ID field in the request body), check:

1. Does the handler verify the requesting user is authenticated? (First gate.)
2. SEPARATELY, does it verify the requesting user actually owns, is assigned
   to, or has a role-based right over THIS SPECIFIC object — via a database
   lookup (an ownership column, an assignment/junction table, or an
   equivalent check) — before reading, writing, or deleting it? Flag any
   route that has gate 1 but not gate 2.

3. Prioritize DELETE and PATCH/PUT handlers — these are the highest-impact
   version of this bug.

4. Check any caching layer (Redis, in-memory, CDN) for cache keys built only
   from an object ID without the requesting user's ID folded in, and confirm
   the authorization check happens before the cache is read, not after.

5. Check whether object-level access logic is duplicated across many similar
   routes (e.g. several `[id]/route.ts` files) versus centralized in one
   shared helper — duplication is how these gaps slip in silently when a new
   similar route is added later.

For each finding: file and line, a concrete exploit scenario (what would an
authenticated-but-unauthorized user be able to do), and a fix that reuses any
existing correct access-control pattern already present elsewhere in this
codebase. Do not fix anything yet — just report.