Is your Lovable app’s database public? A 60-second check.

Why this happens

Lovable, Bolt and most AI app builders connect to Supabase from the browser using the project’s anon key. That key is meant to be public. What protects your data is row-level security (RLS): rules in Postgres that decide which rows each request may read or change. A table with RLS switched off is readable by anyone who has the anon key, and the anon key is visible in your site’s JavaScript.

The 60-second check

Open your Supabase project, go to the SQL editor and run:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Every row with rowsecurity = false is a table without RLS. If it holds users, orders, messages or anything personal, treat it as exposed.

How to fix it

1. Turn RLS on for each table: alter table public.profiles enable row level security;
2. Add policies so people only reach their own rows, for example: create policy "read own profile" on public.profiles for select using (auth.uid() = user_id); Add separate policies for insert, update and delete.
3. Test while logged out. Call your table through the REST API with only the anon key. You should get an empty list or an error, not data.
4. Check storage buckets. A public bucket serves every file to anyone with the URL. Make private anything that holds user uploads.
5. Search your frontend for the service_role key. It bypasses RLS completely and must only ever live on a server.

Common traps

• Turning RLS on with no policies blocks your own app too. Add the policies in the same change.
• A policy of using (true) is the same as no protection.
• Views and database functions can bypass RLS depending on how they are defined. Review them as well.

Want a second pair of eyes?

We do free 20-minute audits of AI-built apps. A senior engineer looks at your app and gives you a ranked list of what's risky. Get a free audit.