Can one customer read another customer's private row?
I'm working on VibePenTester, an open-source security testing project. Its new Supabase alpha checks that question with real application users.
Alice owns a test row. Bob and a signed-out visitor must not be able to read it. Alice and Bob are users in your app, not coding agents.
The checker verifies both login sessions and confirms Alice can read the expected row before testing the other requests. An expired session or an empty owner result cannot pass as a successful security check.
Supabase example and setup guide
This is an early alpha. It checks configured reads, not writes, Storage, or your whole app's security. The runnable example uses a dedicated local Supabase project.
Would you try this on one private table, or do your existing tests already cover it?
Simo Rachidi discusses an open-source security testing project, VibePenTester, which checks Supabase row-level security using real application users. The project ensures that users like Alice can read their own data while others like Bob cannot. The tool is in early alpha and focuses on read access, not writes or full app security. Elijahbrownsk-png suggests improvements for future write checks.
Refusing to pass on an empty owner result is the right default, because a check that can't see Alice's row would otherwise look exactly like a secure table. When you move to writes, the case I'd add first is Bob inserting a row with Alice's user id in the owner column, since an insert policy with a loose WITH CHECK lets that through while every read test stays green. And yes, one private table is a sensible first try.