Is my Supabase app leaking data between users?
It might be, and you can’t tell from the app’s UI. If row-level security is off or a policy is too open, anyone with your public anon key can query the table directly, and the Launch Audit checks every table for this.
Of 1,072 vibe-coded apps scanned, 172 let anyone delete records from the database without logging in.
Why this happens
In apps built with Lovable, Bolt and similar tools, the browser talks to Supabase directly with the anon key. That key is public by design. Row-level security (RLS) policies are the only thing deciding which rows each request can read or change.
What I check
- RLS is turned on for every table in exposed schemas.
- Policies compare rows to auth.uid(), not to a value the client sends.
- Insert and update policies stop users from setting someone else’s user_id or their own role.
- Storage buckets have policies too, and private files are not public.
- Views and functions do not bypass RLS by running as the owner.
- I test it: two test accounts, one tries to read and change the other’s data.
A quick check you can do now
In the Supabase dashboard, open Database, then Tables. Any table marked as having RLS disabled can be read by anyone with your anon key. Supabase’s Security Advisor also lists them. Turning RLS on without policies blocks all access, so add policies before you switch it on in production.