Lovable app security checklist

What to check before a Lovable-built app takes real users, in the order the problems usually appear.

Lovable apps share a shape: a React front end (Vite), Supabase for auth, database and storage, often Stripe through an edge function, often an AI feature through another. The tool writes working code fast. What it does not do, unless you ask precisely, is decide who is allowed to do what. That is where nearly every serious issue in a Lovable app lives. This list is specific to that stack; the general version is the checklist.

Row-level security first

• Open the Supabase dashboard, Table Editor, and look at each table's RLS badge. Every table must have RLS enabled. Then read the policies: using (true) on anything that holds user data is the classic Lovable finding. The Supabase RLS audit walks the exact queries.
• Lovable often generates a "profiles" table whose policy lets any signed-in user read all profiles. If that table carries emails, names or plan status, that is a data exposure.
• Admin flags. If there is an is_admin or role column, check the UPDATE policy: can a user set it on their own row?

Keys in the browser

• The anon key and project URL in the bundle are expected. The service-role key is not. Search the repository for service_role and for any VITE_ variable whose name contains SECRET, KEY or TOKEN that is not the anon or a publishable key.
• Stripe: pk_ keys may be public; sk_ and whsec_ keys must not appear anywhere the client can reach, including a committed .env.
• AI keys (OpenAI, Anthropic, Gemini) called straight from the browser are a bill anyone can run up. They belong in an edge function, behind auth and a limit.

Edge functions

Lovable puts server logic in supabase/functions/. For each function:

• Does it verify the caller? A function that creates a Supabase client with the service-role key and takes user_id from the request body lets anyone act as anyone. Use the caller's JWT from the Authorization header and derive the user from it.
• Stripe webhooks: the handler must call constructEvent with the signing secret before trusting the payload, and must handle the same event id twice without fulfilling twice.
• Checkout: the price or amount must come from your database or a Stripe price id, never from the client request.
• Rate limits: AI and email-sending functions need a per-user or per-IP limit. Supabase does not add one for you.

Auth settings

• Email confirmation off is convenient in development and lets anyone register with someone else's address in production.
• Password reset and magic-link flows: check the redirect URL allow-list so a crafted link cannot send the token to another origin.
• If the app has an admin area, confirm the check happens in a policy or an edge function, not only in a React route guard.

Storage

Buckets created as public serve every file to anyone with the path. Avatars may be fine; uploaded documents are not. Check the storage policies and whether object paths include the user's id.

Before you ship

Run npm audit once. Remove the demo data and test accounts from the production project. Turn on Supabase's built-in security advisor and read what it says about RLS. Keep the generated code in git so a later review has history to look at.

When you want it done for you

Repo Review is a static review of your repository: every item above and the full seven-area checklist, read in your code and judged reachable or not, with the file and line and a fix snippet for each finding. HTML and PDF report within 48 hours, from $79. See the sample report first.

Order a review, from $79 How it works