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 stuck on USING (true). Here's the checklist I run 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, don't launch. Enable RLS on every user table and policies keyed off auth.uid() or membership tables for orgs.

#Secrets and keys

• Anon or 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's connected, and offer disconnect. Don't reuse one founder OAuth token for every customer. That's 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 show security or trust pages for published apps. Treat those as signals, not a substitute for RLS and secret hygiene. Buyers still ask if other users can see their data. Your answer should be a policy and a test, not a badge.

#If this feels heavy

That's normal. Most Lovable rescue work I do is this checklist after a near-miss. Want a production audit before launch? That's what the Lovable Developer and Supabase pages are for.