The failures in vibe coding are boringly consistent. It is almost never a clever exploit — it is a default setting nobody changed, a key in the wrong place, or a bill nobody capped. All three are avoidable in one session.
Row Level Security. If you read nothing else here, read this.
When you use Supabase, your database is exposed directly to the browser through an API. That is by design, and it is fine — as long as the database itself enforces who can read which rows. That enforcement is called Row Level Security, and on a new table it is off.
The public key that ships in your JavaScript is meant to be public. But with RLS off, that public key is effectively an admin login: anyone who opens developer tools can read, modify or delete every row in every unprotected table.
-- The policy people end up with. This is the same as no security at all. CREATE POLICY "users can read" ON profiles FOR SELECT USING (true); -- What it should be: scoped to the person actually asking. ALTER TABLE profiles ENABLE ROW LEVEL SECURITY; CREATE POLICY "read own profile" ON profiles FOR SELECT USING (auth.uid() = user_id);
Open your Supabase dashboard, go to Authentication then Policies, and confirm every table has RLS enabled with a policy that references the logged-in user. Then create two accounts, log in as the first, and try to load the second one's data by changing an ID in a request. If it succeeds, you have the problem.