Lovable security checklist for founders before you launch

Lovable ships UI fast. Security is still your job. Founders often launch with open tables, service keys in the client, or “temporary” policies left on USING (true). Here is the checklist I walk through before a Lovable app gets real users — whether you use Lovable Cloud, Supabase, or both.

#Auth and identity

• Sign-up, login, logout, and password reset work on the production domain.
• Email verification or OAuth callbacks match the live URL allow-list.
• No shared admin password in the README or a public Notion page.

#Data isolation (RLS)

Create two test users. Insert data as A. Sign in as B. If B can see A’s rows, do not launch. Enable RLS on every user table and policies that key off auth.uid() (or membership tables for orgs).

#Secrets and keys

• Anon/public keys only in the browser; service role never ships to the client.
• Stripe, OpenAI, and SMTP secrets live in host env / server functions.
• Rotate any key that ever appeared in a screenshot or Git commit.

#Connectors and third-party data

If users connect Google, Slack, or other tools, store tokens per user, show what is connected, and offer disconnect. Do not reuse one founder OAuth token for every customer. That is a breach waiting to happen.

Launch security gate:
[ ] Two-user RLS test passed
[ ] No service_role in client bundle
[ ] Production auth redirects only
[ ] Privacy / terms linked if you collect PII
[ ] Backup / export plan for your own data

#Trust pages vs real controls

Lovable and similar platforms may surface security or trust pages for published apps. Treat those as signals — not a substitute for RLS and secret hygiene. Buyers still ask “can other users see my data?” Your answer must be a policy and a test, not a badge.

#If this feels heavy

That is normal. Most Lovable rescue work I do is exactly this checklist after a near-miss. If you want a production audit before launch, that is what the Lovable Developer and Supabase pages are for.