UnbreakMyApp / Fix guides

Supabase Row Level Security is off: your app data may be public

If Row Level Security (RLS) is disabled or too permissive, anyone with your public key can read or edit your tables. Here is how to check and fix it.

Why it happens

Lovable and other AI builders talk to Supabase straight from the browser using a public key (the anon or publishable key). That key is meant to be public. It is safe only because Row Level Security (RLS) rules decide what each user can see.

If a table in the public schema has RLS turned off, anyone who copies that key from your site can read, change or delete every row. If RLS is on but a policy says "true" for everyone, the result is the same.

With RLS enabled and no policy, nobody can access the table through the public key. That is safe, but it can make your app look empty.

How to fix it, step by step

  1. In Supabase → Table Editor (or Database → Tables), look for tables marked "RLS disabled" / "Unrestricted". Also check Advisors → Security Advisor.
  2. Enable RLS on every table in the public schema: ALTER TABLE public.your_table ENABLE ROW LEVEL SECURITY;
  3. Add policies that match how the app works. For user-owned rows, for example: CREATE POLICY "own rows" ON public.your_table FOR SELECT TO authenticated USING ((select auth.uid()) = user_id); and add matching INSERT (WITH CHECK), UPDATE and DELETE policies.
  4. Remove any policy that uses USING (true) for writes unless that is truly intended (like an insert-only signup form).
  5. Test while logged out and as a second user. You should not see another user's data.
  6. If data was exposed, consider rotating keys and checking logs, and tell affected users if required.

Paste-ready prompt for Lovable

Audit my Supabase security. For every table in the public schema:
1. Enable Row Level Security if it is off.
2. Write policies so users can only SELECT, INSERT, UPDATE and DELETE their own rows (using auth.uid() = user_id or the right owner column). Use WITH CHECK on INSERT/UPDATE.
3. List any table that needs to be publicly readable and explain why before making it public.
4. Remove any policy that allows everyone (USING true) to update or delete.
Output the SQL migration and a short table showing each table, who can read it, and who can write it.

FAQ

Is it bad that my Supabase key is visible in the browser?

Not if it is the anon/publishable key and RLS is set up correctly. It is very bad if it is the service_role or secret key, which bypasses RLS completely.

Does Lovable's security scan catch this?

Lovable has built-in security scans, which are a good start. Still test policies yourself by trying to read another user's data.

Still broken?

Get a free diagnosis by email within 24 hours. Fixed or refunded.

Get a free diagnosis

Or join the waitlist for updates:

Sources