Testing Supabase row-level security with two real users — open-source alpha

[firetix]

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?

[elijahbrownsk-png]

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.