Lovable app security checklist: 10 checks before you publish

1. Run Lovable's own security scan, then read the findings

Lovable's docs describe a Quick scan that runs automatically on publish (database access rules, dependency audit, unauthenticated MCP servers) and a Deep scan that reviews application code, including access control, abusable endpoints and leaked secrets. Use both. The docs themselves say the scans don't guarantee complete security.

2. Review every RLS policy, not just whether one exists

In Lovable: More → Cloud → Database → RLS policies (per Lovable's docs). A policy with USING (true) counts as 'RLS enabled' but lets every row through. The researcher who reported CVE-2025-48757 criticised an earlier Lovable scanner for checking only that policies exist, not that they're correct. For user-owned data, policies should compare auth.uid() to the owner column.

alter table public.notes enable row level security;

create policy "Owners can read" on public.notes
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "Owners can insert" on public.notes
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

create policy "Owners can update" on public.notes
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

create policy "Owners can delete" on public.notes
  for delete to authenticated
  using ((select auth.uid()) = user_id);

3. Test as a second user and as nobody

Sign up a second account and try to open the first account's records (change IDs in the URL, watch the Network tab). Then log out and repeat. Lovable's security best-practices page recommends verifying that 'users cannot access other users' private data' before going live.

4. Keep the service role key out of the front end

Lovable's docs note that server-side code using the service role bypasses RLS and must check permissions itself. That key belongs only in edge function secrets. If it ever appears in your published JavaScript, rotate it immediately.

5. Put third-party API keys in edge functions

OpenAI, Stripe, Resend and similar keys must be stored as secrets for your edge/server functions, never pasted into React code. Anything in the browser bundle is public.

6. Make edge functions check who is calling

An edge function that sends email, calls an AI API or touches payments must verify the caller's JWT and permissions, or it becomes a free, abusable endpoint.

7. Check storage buckets

Public buckets serve every file to anyone with the URL. Keep uploads like invoices or ID documents in private buckets with storage policies.

8. Turn on leaked-password protection and email confirmation

These are auth settings in your Supabase/Lovable Cloud project. Lovable's Quick scan flags leaked-password protection being off.

9. Add security headers on your custom domain

If you host the app yourself (e.g. Vercel or Netlify), add CSP, HSTS, X-Frame-Options and nosniff with the snippets in our header guides. On builder-managed hosting, check what headers you can configure.

10. Scan the published URL

Run Unspill against your live URL to catch leaked keys, public source maps, an exposed .env and missing headers. It reads only public files and never queries your database.