Lovable apps, RLS, keys, and auth

Lovable's own Supabase guide says missing row level security policies are the most common way app data gets exposed, and that secret keys must stay out of the client.

Share link · Share on X

Last updated Oct 14, 2026

criticalDatabase

Shows up in: Supabase

Markdown version

What it is

Lovable's Supabase integration doc says the built-in backend uses Supabase's database, auth, storage, and edge functions, and that you can also connect your own Supabase project. The same page says Lovable checks Row Level Security coverage after schema changes, and that missing RLS policies are the most common way app data gets exposed.

Sign-in on that page is Supabase Auth: email and password, social login, and access control. A screen that hides a button is not that control. Supabase's securing-data guide says the publishable key is safe to put in the client only when RLS and grants are in place, and that a secret key bypasses RLS and must not be exposed.

How to check in 5 minutes

In Lovable, open the database view and the Supabase dashboard. For each public table, confirm RLS is enabled and the policy names who can read and write a row. Lovable's doc says to verify this yourself, not only to trust the automated check.
Search the project for VITE_ and for SERVICE_ROLE. Lovable's secrets doc says VITE_ values are embedded in the client bundle, and that SUPABASE_SERVICE_ROLE_KEY is injected into Edge Functions. It must not appear in frontend code.
Sign out and request a row you should not see, using the publishable key the client already has. An empty result or a permission error is the pass. A row of someone else's data is the failure Supabase documents when RLS is off or the policy is open.

How to fix

Lovable

Ask Lovable to restrict each table to the signed-in user, then open the Supabase dashboard and read the policy. Lovable's integration doc gives the example prompt "Make sure users can only see and edit their own data." Put private keys in Secrets, not in .env under a VITE_ name. Lovable rejects a VITE_ name in Secrets and says those values belong in .env because they are browser-exposed.

Supabase

Enable RLS and add policies for anon and authenticated. Supabase's API key guide says policies never apply to a secret key, because service_role has BYPASSRLS. Keep that key in the Edge Function environment Lovable already populates. Do not prefix it with VITE_.

Copy-paste prompt

Paste this into Cursor, Claude Code, or whichever agent is editing the repo. Read the diff before you merge it.

You are fixing data access in a Lovable project. Do not add features.

1. List tables exposed to the client. Enable RLS and replace any policy that lets every caller read or write every row.
2. Search for VITE_ variables and for SERVICE_ROLE. Leave only publishable values in VITE_. Move secret keys into Lovable Secrets or Supabase edge-function secrets.
3. Show me the policy SQL and the file where the browser client is created. Do not claim the app is safe.

Questions

Does Lovable's publish scan replace reading the policies?

No. The security page says a basic scan runs on publish and checks RLS, in about 10 to 15 seconds. The Supabase integration doc still says to verify policies in the dashboard. A deep scan is a separate on-demand pass of about 3 minutes.

Are Lovable secrets copied when someone remixes the project?

Lovable's secrets doc says manually added secrets are not copied into a remix. Lovable-generated keys are recreated. A remixed app will not have your Stripe or model key unless someone pastes it again.