How to secure your Lovable app before launch

Lovable apps usually use Supabase for the database and login. That is a good setup, but the safety of your data depends on settings the chat does not always get right.

1. Turn on Row Level Security for every table

Lovable talks to Supabase from the browser with the public anon key. Only Row Level Security protects your tables from that key. In Supabase, open Table Editor and look for an “RLS disabled” badge.

Paste this into the Lovable chat:

Enable Row Level Security on every table in the public schema. Add policies so each signed-in user can read and change only their own rows (using auth.uid()). Do not create policies that allow everyone. List every table and policy you changed.

2. Keep secret keys out of the page

Anything in your components ships to the browser. If you added an OpenAI, Stripe or other secret key, move the call into a Supabase Edge Function and store the key as a Supabase secret.

Find every place a secret API key is used in the frontend. Move that call into a Supabase Edge Function that reads the key from Deno.env, and make the frontend call the function. Remove the key from the code.

Then rotate the key at its provider. The old one was public.

3. Check your Edge Functions

Edge Functions are public URLs. A function that reads or writes user data must check who is calling.

In every Supabase Edge Function that touches user data, verify the caller’s JWT and return 401 if there is no signed-in user. Use the user id from the token, never from the request body.

4. Check storage buckets

A public bucket is fine for logos. It is not fine for invoices or uploads. Make private buckets private and use signed URLs.

Re-scan

Enter your published Lovable address (it ends in .lovable.app, or your own domain) in Greenlight Scan. The free preview shows how many problems exist; the full scan lists each with a prompt like the ones above. Fix, publish again, and re-scan until it comes back Greenlit.