Checklist
How to secure a Lovable app before launch
Short answer. Read where the data lives, keep secrets out of VITE_ variables, and review row level security before you publish. Lovable runs a Quick scan from the publish dialog. Its own docs say the scans do not guarantee complete security.
Updated 19 Oct 2026
This is a practical checklist, not a guarantee. It is not a penetration test, a compliance audit, or proof that an app is safe to launch.
This is the launch pass for one Lovable project. The ship checklist for Lovable is the short version. The pre-launch checklist is the general pass after this one.
See which backend this project uses
Lovable's Cloud backend and a Supabase project you connect yourself are different dashboards.
- Cloud stores its own secrets. Lovable's secrets docs say names that start with
SUPABASE_are filled in for you, including the service role key, and Edge Functions can read them. You review policies under More, then Cloud, then Database, then RLS policies. - A connected Supabase project keeps secrets in Supabase. The Cloud view shows a button that opens that project's dashboard.
Write down which one you have. The Supabase tool page and the row level security checklist apply to both, because both speak Postgres policies. They do not apply to a project that stores its data somewhere else.
Sort public values from secrets
Lovable generates a frontend that runs in the browser. Its security overview says API keys cannot live safely in that client code. Pasting a key into the project chat is supposed to send you to Secrets instead of into the source.
| Value | Where Lovable says it belongs |
|---|---|
VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY | The project's .env file. These are embedded in the client at build time. |
STRIPE_SECRET_KEY, RESEND_API_KEY, an OpenAI key, and other credentials | Secrets. They are injected into Edge Functions and are not part of the browser bundle. |
SUPABASE_SERVICE_ROLE_KEY and the other SUPABASE_ names | Reserved. Lovable fills them for Cloud, or you manage them in Supabase. Server code that uses the service role bypasses row level security. |
Lovable's secrets docs also say to keep .env committed. The build needs the VITE_ values for previews and published builds. That file is for the public values only. A secret in .env is in the repository and in the bundle.
The API key checklist is the longer version of this sort.
Remember that preview and production share data
Lovable's preview docs say the preview shows your latest edit, and the published site updates when you publish. They also say the preview and the published app share the same backend and data. A policy change, a deleted row, or a test user is live for both.
Treat a preview that contains real personal data as production. Do the access test before you invite someone to click around.
Read the row policies
Lovable's database docs say it sets up row level security when it builds features that store user data, and that you should review the rules. The RLS policies screen lists the policy name, the command (select, insert, update, delete), who it applies to, and the expression. That screen is read-only. Ask in the project chat to change a policy.
Before you publish, confirm:
- Every table that holds private data has row level security enabled.
- A signed-in user can read their own rows, and a second test user cannot.
- A policy for anonymous visitors is there only for data you mean to be public.
- Server functions that use the service role check the caller themselves. Lovable's best-practices page says that role bypasses row level security.
The database and auth category is the rest of the stack if this project is not on Supabase-style Postgres.
Use the scan Lovable already runs
Opening Publish runs a Quick scan. Lovable's publish docs say it takes about 10 seconds and checks database access rules, dependencies, and MCP server exposure. Findings do not block publishing unless a workspace admin has turned on "Block publishing with critical issues." New Enterprise workspaces start with that block enabled. Other workspaces can still publish with findings on the screen.
The Quick scan covers tables without per-record access control, rules that let everyone through, leaked-password protection, known vulnerable npm dependencies, and an MCP server exposed without authentication. Lovable says only critical dependency vulnerabilities become findings, and some of those are still hidden when Lovable has decided they cannot affect Lovable apps or when their exploit score is low.
The Deep scan is separate. The publish dialog does not run it. Lovable's publish docs say it usually takes 3 to 13 minutes, and at most 15, and that it reviews application code for issues such as exposed secrets, unsafe input, and authorization gaps. Run it from the project Security view before you share the URL.
Lovable's security overview says these tools do not guarantee complete security, and that you are responsible for the app. A clear scan is a clear scan. It is not a certificate. If you want a second pass from outside Lovable, use something in the security scanners category against the URL you will actually share.
Payments and email
Lovable's Deep scan looks for prices, fulfillment, or paid features a customer can change or reach without paying. The browser still must not be the thing that decides a charge succeeded. If you use Stripe, follow the webhook checklist and keep the secret in Secrets. The payments category lists the checkout products. Receipts and password resets belong on a server call through an email API.
FAQ
Does Lovable block an insecure publish?
Only if a workspace admin has enabled "Block publishing with critical issues." Lovable's publish docs say findings do not block publishing by default. New Enterprise workspaces start with the block turned on. On any plan, the publish dialog runs the Quick scan and links you to the findings.
Is the Supabase publishable key in a Lovable project a leak?
No, when it is the publishable key and row level security is on. Lovable tells you to put VITE_SUPABASE_PUBLISHABLE_KEY in .env because the browser needs it. The service role key is reserved for server code and bypasses those policies.
Do the preview and the published site have separate databases?
No. Lovable's preview docs say they share the same backend and data. Visitors see the last published snapshot of the interface. Database edits show up on both.
What should I run after Lovable's scan?
Walk the pre-launch security checklist on the URL you will share, with a second user account. Lovable says its own scans do not replace a review, especially if the app handles sensitive data.
Sources
Checked 19 Oct 2026.
Newsletter
A short weekly note on new tools and security checklists. No spam, unsubscribe anytime.