Supabase tables without Row Level Security are public

With Row Level Security off, or a policy of using (true), the public anon key in your app lets anyone read, change or delete every row. The app still works, which is why nobody notices.

What you see

Nothing looks wrong: the app works in every test. But anyone can open the browser's developer tools, take the Supabase URL and anon key, and query your tables directly.

Why it happens

Supabase gives the browser a public key and relies on Row Level Security (RLS) to decide what each user may see. A table created without RLS, or with a policy that allows everyone (using (true) on an insert, update or delete), protects nothing.

How to fix it

1. In Supabase → Table editor, make sure every table shows RLS enabled.
2. For each table, add policies tied to the signed-in user, e.g. using (auth.uid() = user_id).
3. Keep using (true) only for read policies on data that's meant to be public.
4. Test it: sign in as one user and try to read another's rows.

Or ask your AI tool to fix it

Paste this into Lovable, Bolt, v0, Replit or Cursor:

Enable Row Level Security on every table in the public schema, and add policies so each user can only read and change their own rows (auth.uid() = user_id), with public read access only where data is meant to be public. Add it as a new migration, and don't remove any existing data.

The full page, with the request ready to copy, is at launchpad.axonscape.com/fix/supabase-row-level-security. I work on Launchpad by Axonscape, which runs a free launch check for apps built with AI tools: it finds this and the other things that break at launch, from a public GitHub repo or a .zip of the code, and keeps nothing.