Checklist

Is Lovable secure? What to check before you launch

Short answer. Lovable's own security overview says its scans help find common issues and cannot guarantee complete security. Before you share a URL, sort VITE_ values from secrets, review row level security with a second user, and read what two newsrooms reported about public projects in April 2026.

Updated 26 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 page answers the question with the checks, not with a yes or a no. Lovable can host the app and may attach its own backend. The project you have open is the thing to review. The longer project pass is how to secure a Lovable app before launch. The short list is Ship a Lovable app.

What Lovable's docs say the product does

Lovable's security overview says the product tries to prevent common mistakes and to flag issues with two scans, Quick scan and Deep scan. The same page says these tools cannot guarantee complete security, and that you are responsible for the app, especially if it handles sensitive data.

Quick scan runs when you publish. Lovable says it covers database access rules (tables without per-record row level security, rules that let everyone through, leaked-password protection turned off), known vulnerabilities in npm dependencies, and an MCP server exposed without authentication.

Deep scan adds a review of application logic. Lovable lists access control, unauthenticated endpoints, unsafe input, and leaked secrets among the areas it reports. A clear scan means that pass found nothing it reports.

Lovable generates a frontend that runs in the browser. Its security overview says API keys cannot live in that client code, and that pasting a key into the project chat should send you to Secrets instead of into the source. Secrets are encrypted, injected into Edge Functions, and are not part of the browser bundle. Anything prefixed with VITE_ is a build-time browser value and belongs in .env, not in Secrets. Lovable says to keep .env committed so previews and published builds can read those public values. A secret in .env is in the repository and in the bundle.

VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY are the public pair. STRIPE_SECRET_KEY, RESEND_API_KEY, and an OpenAI key are Secrets. Names that start with SUPABASE_, including the service role key, are reserved. Server code that uses the service role bypasses row level security. The anon-versus-secret distinction is Is the Supabase anon key safe to expose?. If that elevated key is already in the bundle, the repo, or the chat, use Supabase service role key exposed.

Preview data and the published URL

Lovable's preview docs say the preview always shows your latest working version, and the published site is a snapshot that changes when you publish. They also say the preview and the published app share the same backend and data, so a database change in the preview is live for visitors.

There is an exception for older projects. Lovable's Test and Live environments page says that, as of 24 Mar 2026, that split cannot be enabled on new Cloud projects. Projects that already use it keep a separate Test database, and publishing syncs structure, not the Test data. If your project does not have that split, treat the preview database as production data.

A shared preview link can be opened without a Lovable account. On Free and Pro plans, Lovable says those links expire after 7 days. Anyone with the link can view the working app while it is active.

Row level security

Lovable says it sets up row level security when it stores user data, and that you should review the policies. The policies view is under More, then Database, then Manage, then Policies. That view is read-only. You change a policy by asking in the project chat, then you test it.

The test is two users, plus logged out. User B, using the same client, should not receive user A's rows. An empty result is the pass. The copy-paste policies and the "RLS is on but the query still returns rows" cases are in how to set up Supabase row level security. A connected Supabase project uses the same policies; you edit them in Supabase rather than in the Cloud view.

What The Register and Fast Company reported in April 2026

On 21 Apr 2026, The Register and Fast Company both reported a researcher's claim about public Lovable projects. The notes below are what those articles report. They are not a finding by this site, and they are not a description of every project.

The Register reported that a researcher posting as @weezerOSINT said a newly created free account could read another user's source code, database credentials, AI chat histories, and customer data, and described the issue as affecting projects created before November 2025. The Register said the researcher had reported it through HackerOne, with screenshots showing a 3 Mar 2026 submission closed as a duplicate. The Register described the issue as broken object-level authorization: the researcher said five API calls from a free account reached another user's profile, public projects, and source code, and that database credentials were then read from that source.

The Register quoted Lovable's first public response. The company said it had not suffered a data breach, that its documentation of what "public" means was unclear, and that visible code on public projects was intentional. The article also said Lovable noted that chat messages on public projects used to be visible. In an update the same day, The Register reported that a Lovable spokesperson said the company learned of the issue that Monday and addressed it then; that HackerOne had closed the reports without escalating them because public-project chats had historically been treated as intended; that a user could switch a project from public to private; and that chats from public projects were no longer visible.

Fast Company, the same day, reported the researcher's account that chat histories, source code, and customer data in public projects were reachable through an API, including projects created before November 2025. Fast Company reported that the researcher said the work took 30 minutes with a model, that the HackerOne report was filed in early March, and that Lovable pointed to its statement on X rather than putting an executive on the record. Fast Company reported that Lovable's initial statement treated visible project code as intentional for projects marked public, and that this did not account for the exposure of chats and prompts.

If a project of yours was public in that period, read those two articles, then rotate any credential that was in the project chat or in source. This page cannot tell you whether a given project was viewed.

Before you launch

Write down whether data lives in Lovable Cloud or in a Supabase project you connected. The dashboards are different.
Open .env and Secrets. Every VITE_ name is public. No secret key belongs there.
Open Policies. Run the two-user test. Do not turn row level security off to make a query work.
If you charge, the browser must not be the thing that decides a customer paid. Use the Stripe webhook checklist.
Publish only after Quick scan has run, and read what it flagged. Then run a free passive check on the URL you will share, and finish the pre-launch checklist.

FAQ

Does a clear Quick scan mean the app is finished?

No. Lovable's security overview says the scans cannot guarantee complete security. Quick scan is a fixed set of checks. Deep scan is a broader pass over the code. Neither one is a substitute for the two-user data test.

Are VITE_ Supabase keys supposed to be in the project?

Lovable's secrets docs say VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY belong in .env and are embedded in the client. The service role key does not. If the publishable key is the only Supabase key in the bundle, the remaining question is whether row level security and the grants match what that key should be allowed to do.

Do the preview and the live site use different data?

Not by default. Lovable's preview docs say they share the same backend and data. The published site is a snapshot of the code. Test and Live environments, which do separate the data, cannot be turned on for new Cloud projects as of 24 Mar 2026, according to Lovable's docs. Existing projects that already use that split keep it.

Where is the rest of the Lovable launch list?

How to secure a Lovable app before launch is the project walkthrough. Ship a Lovable app is the short version. Lovable is the directory entry.

Sources

Checked 26 Oct 2026.

Informational only. This page describes checks and vendor documentation. It is not a security audit, a penetration test, or a certification, and it is not a guarantee.

A short weekly note on new tools and security checklists. No spam, unsubscribe anytime.