Onlook Design Updates: Closing a Cross-Project Access Gap
A single security fix closes an IDOR vulnerability that let authenticated users potentially read, modify, or delete other users' project data across most tRPC procedures. PR #3127 extends an existing access-check helper to the areas that were missing it.
Duration: PT2M20S
Episode overview
This episode is a short developer briefing from Onlook Design Updates.
It explains recent repository work in plain language.
- Show: Onlook Design Updates
- Published: 2026-07-14T13:16:56Z
- Audio duration: PT2M20S
Transcript excerpt
This excerpt keeps the crawler page concise. Listen to the episode or use the RSS feed for the full update.
Good day, and welcome to Onlook Design Updates for July 14th, 2026.
Today's activity is small in volume but high in stakes: one pull request that closes a real security gap in how project access is checked across the backend.
Here's the core issue. Onlook's database client connects with a Postgres superuser role, which means it bypasses Supabase's row-level security entirely. That's a deliberate tradeoff, but it puts the full weight of authorization on the application code itself — specifically, on a helper function called "verify…
Practically, that meant any authenticated user could potentially reach into another user's project data — reading it, changing it, or deleting it — simply by knowing or guessing the right identifiers. This is a textbook insecure direct object reference, or IDOR, and it's about as serious as backend bugs get, since…
The fix itself is a pattern, not a one-off patch: go through the tRPC procedure layer and make sure every project-scoped call — conversation access, messaging, branch operations, fork creation, frame handling — actually runs through that same access-verification helper before doing anything. The theme here is…
What to remember: if you're adding…