fix(security): enforce project membership across tRPC procedures (IDOR) - #3127

Summary

Closes #3122.

The Drizzle client connects via a Postgres superuser role that is exempt from Supabase RLS, so authorization has to be enforced in tRPC procedure code. A verifyProjectAccess() helper already existed (project/helper.ts) and was used correctly in a few procedures (project.update, project.delete), but was missing from the large majority of project-scoped procedures — any authenticated user could read, modify, or delete data belonging to other users' projects by supplying an arbitrary projectId/conversationId/branchId/etc.

I audited every router under server/api/routers/{project,chat} (not just the 15 procedures the original report named) and fixed everything I found unprotected — 25 procedures across 9 files:

• project.ts: get, getProjectWithCanvas, getPreviewProjects (now pins to the caller's own session id rather than trusting a client-supplied userId)
• fork.ts: fork — clones a source project's entire contents (canvas, branches, live sandboxes) into a new project the caller owns; not in the original report, found while auditing this router
• member.ts: list, remove
• invitation.ts: list, delete, create (create also unprotected, not in the original report — lets any user invite arbitrary emails into any project)
• chat/conversation.ts: getAll, get, upsert, update, delete
• chat/message.ts: getAll, upsert, upsertMany, update, updateCheckpoints, delete, replaceConversationMessages (this one also had a secondary issue: it deletes-then-inserts using input.conversationId for the delete but each message's own embedded conversationId for the insert — a caller authorized for conversation A could smuggle messages into conversation B via the array. Now forces every inserted message onto the authorized input.conversationId server-side.)
• branch.ts: getByProjectId, create, update, delete, fork, createBlank
• settings.ts: get, upsert, delete
• frame.ts: get, getByCanvas, create, update, delete
• createRequest.ts: getPendingRequest, updateStatus

Approach

Added resolve-then-verify helpers to project/helper.ts for resources that don't carry a projectId directly, each following the exact pattern the existing verifyProjectAccess already uses (single query, merged "Unauthorized or not found" error so the check itself can't be used to enumerate resource existence):

• verifyConversationAccess — conversation → projectId
• verifyMessagesAccess — message(s) → conversation → projectId (accepts an array for bulk ops like delete, verifies every resolved project)
• verifyBranchAccess — branch → projectId
• verifyCanvasAccess — canvas → projectId
• verifyFrameAccess — frame → canvas → projectId
• verifyInvitationAccess — invitation → projectId

Every mutation/query call site gets one await verify*Access(ctx.db, ctx.user.id, ...) at the top, before touching the DB. No new abstractions beyond that — same helper file, same error shape, same call convention already established in the codebase.

Not covered here

project/sandbox.ts operates on raw CodeSandbox provider ids (start/hibernate/delete/fork), not projectId-keyed DB records — it needs a different resolution path (sandboxId → branches.sandboxId → projectId) and felt like a separate enough concern to not fold into this diff. Happy to follow up with that in a second PR if useful.

Test plan

• tsc --noEmit run per changed file (isolated, without bun install — this repo's bun.lock is large and I didn't want to pull the whole dependency tree for a security-fix diff). Every error that surfaced traced back to unresolvable @onlook/db imports in that isolated setup; I confirmed the specific patterns used (e.g. the Set-dedup + type-guard in verifyMessagesAccess's caller) compile clean under --strict with equivalent real types in isolation.
• Would appreciate a maintainer running the full bun run typecheck + bun test suite against this branch, and ideally exercising the original repro from Cross-user IDOR across multiple tRPC procedures #3122 against it, since I don't have a local Supabase stack set up to verify end-to-end myself.
• Read through every touched procedure to confirm the added check doesn't change behavior for an authorized caller — only rejects callers who aren't a member of the resolved project.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Security
  • Strengthened access controls across projects, conversations, messages, branches, canvases, frames, invitations, members, and settings.
  • Prevented unauthorized reads, updates, deletions, and creation of project-related content.
  • Added validation to prevent messages from being inserted into the wrong conversation.
  • Ensured project previews can only be requested for the authenticated account.
  • Standardized unauthorized or missing-resource responses.