# Is Lovable Safe? The Platform, Your App, and What to Check

URL: https://tuvio.dev/blog/is-lovable-safe
Published: 2026-10-19
By the Tuvio team

Is Lovable safe? As a place to build, mostly yes: it is a hosted tool with account security, private projects by default and its own security scans. Whether the app you built with it is safe to put in front of users is a separate question, and the honest answer is "only after you check". Most of the real risk sits in the database your app talks to, and that part is yours.

This post keeps those two questions apart, covers the documented Lovable security vulnerability (CVE-2025-48757), describes what Lovable offers today, and ends with a check you can run on your own app tonight.

## Is Lovable safe to use?

Yes, for building, with normal care: turn on two-factor authentication, keep keys out of the chat, and review who can open your workspace. The bigger question is your app. A Lovable app reads and writes its database straight from the browser, so the database rules (row level security) are what keep one user out of another user's data.

That second point is what CVE-2025-48757, the best-known Lovable security issue, was about. The platform hosts your code. The rules that decide who can read the `profiles` table are code too, and an assistant can write them wrong.

## Is the Lovable platform secure?

Is Lovable secure as a service you log into? "Platform" here means your Lovable account, your project's code and its chat history.

What you control:

- **Two-factor authentication.** Lovable supports [2FA on your account](https://docs.lovable.dev/introduction/two-factor-authentication-2-fa). Turn it on. Your account can change your production app.
- **Project access.** Lovable's docs separate *project access* (who can open the editor, the code and the chat) from *website access* (who can visit the published app). Per [Lovable's project access docs](https://docs.lovable.dev/features/project-visibility), projects on free plans were public by default before November 6, 2025, new projects default to workspace access since then, and since April 22, 2026 public project visibility has been removed entirely.
- **What you paste into the chat.** Lovable's [security overview](https://docs.lovable.dev/features/security) says it detects API keys pasted into the chat and steers you to store them in Secrets instead.

The project access history matters for one reason. In April 2026 a researcher reported that chats and code on projects set to public could be read from another account. [The Register's report](https://www.theregister.com/security/2026/04/21/lovable-denies-data-leak-cites-intentional-behavior/5226233) carries Lovable's response: it said it did not suffer a data breach, that its documentation of what "public" meant was unclear, and that access to chats on public projects had been accidentally re-enabled in February 2026 and was reverted. If your project was ever public and you pasted a real key into its chat, rotate that key. That costs five minutes either way.

## What was CVE-2025-48757?

This is the documented Lovable Supabase RLS issue and the best known of the Lovable security vulnerabilities. It was about generated apps, not the platform.

The [NVD entry for CVE-2025-48757](https://nvd.nist.gov/vuln/detail/CVE-2025-48757) describes it as an insufficient database row level security policy in Lovable through 2025-04-15 that allows remote unauthenticated attackers to read or write arbitrary database tables of generated sites. The record carries a CVSS 3.1 score of 9.3 (critical). It is also marked disputed: Lovable's position, as the entry records it, is that each customer accepts responsibility for protecting their application's data.

The researcher's [write-up](https://mattpalmer.io/posts/CVE-2025-48757/) and [statement](https://mattpalmer.io/posts/statement-on-CVE-2025-48757/) give the detail:

- Lovable apps call the database's REST API from the browser with the public `anon` key and rely on RLS alone to keep data private.
- The researchers scanned 1,645 projects listed on Lovable Launched and found 303 vulnerable endpoints across 170 projects, about 10.3%. They looked at homepages only, not logged-in areas.
- Exposed data included user emails and other personal details, API keys for third-party services, payment and transaction records, and subscription information. Some endpoints also accepted writes with no login at all.
- Timeline: found March 20, 2025, reported to Lovable March 21, published May 29, 2025.

The mechanism is simple. Anyone can open the browser's network tab, copy the request your app makes to Supabase, change its `select=` parameter to `*`, and read whatever the table's policies allow. If RLS is off, or a policy says `using (true)`, that is every row.

## Does Lovable have a security scanner?

Yes. Lovable's [security overview](https://docs.lovable.dev/features/security) describes two built-in scans, summarized here as Lovable documents them:

- **Quick scan.** Runs automatically every time you publish. It covers a database review (for example, tables without row level security, access rules that let everyone through, and leaked-password protection turned off), known vulnerabilities in npm dependencies, and an MCP server your app exposes without authentication.
- **Deep scan.** Runs when you start it from the Security view. It reviews application code for access control, unauthenticated endpoints, injection, leaked secrets, payments, authentication and exposed personal data, plus everything in the Quick scan.

It also offers auto-fix for eligible Quick scan findings, a conversational review ("Review my app's security"), and optional Wiz and Aikido connectors. For context: when the security scan shipped with Lovable 2.0 in April 2025, the CVE researchers wrote that it checked whether a policy existed, not whether it was correct. The current docs describe the Quick scan as also flagging rules that let everyone through.

Lovable is direct about the limits. Its docs say the tools "cannot guarantee complete security" and that you are responsible for making sure your app meets the security requirements of its use case. Run the Deep scan before you publish. Then do the check below anyway, because a scan tells you what it found, and you want to know what is true.

## Is Lovable safe for production? A pre-launch check

Most of this is Lovable row level security, plus keys and a few settings. These steps work whether your project uses Lovable Cloud (the built-in backend, built on Supabase) or a Supabase project you connected yourself. In Cloud, the SQL editor is under **More → Cloud → SQL editor** and the policies under **More → Cloud → Database → RLS policies**. With your own Supabase project, use the Supabase dashboard.

### 1. RLS on every table, and no using (true)

Run this in the SQL editor. It lists tables in the `public` schema with RLS turned off:

```sql
select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false;
```

The result should be empty. For each table it returns:

```sql
alter table public.profiles enable row level security;
```

Then look for policies that let everyone through:

```sql
select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true');
```

A `using (true)` policy on `select` means everyone in the policy's role, often every visitor, can read every row. That is fine for a table of blog posts and wrong for `orders`. Replace it with an ownership check, one policy per operation, as the [Supabase RLS guide](https://supabase.com/docs/guides/database/postgres/row-level-security) shows:

```sql
drop policy "Enable read access for all users" on public.orders;

create policy "Users can view their own orders"
on public.orders for select
to authenticated
using ( (select auth.uid()) = user_id );
```

Use your policy's real name in the `drop`. Two more patterns to look for while you are there: a policy whose only condition is "signed in" (`to authenticated using (true)`, or `auth.uid() is not null`) lets any user read everyone's rows, and a policy that reads `user_metadata` trusts a value users can edit themselves. More shapes and fixes are in [Supabase RLS policy examples](https://tuvio.dev/blog/supabase-rls-policy-examples).

### 2. No service role or secret key in frontend code

A Lovable frontend is a Vite app. Anything it reads from a `VITE_` variable is built into the JavaScript every visitor downloads. Lovable's [Secrets docs](https://docs.lovable.dev/features/secrets) say the `.env` file is committed on purpose and holds browser-safe values such as `VITE_SUPABASE_URL` and `VITE_SUPABASE_PUBLISHABLE_KEY`. That is fine. The publishable key (or the legacy `anon` key) is meant to be public; RLS is what protects the data.

The secret key (`sb_secret_...`) and the legacy `service_role` key are different. Per [Supabase's API keys guide](https://supabase.com/docs/guides/api/api-keys), they bypass RLS entirely. From the project root:

```bash
grep -rnE "service_role|SERVICE_ROLE|sb_secret_" src/ .env
```

Nothing should match in `src/` or `.env`. The legacy keys are JWTs (long strings starting with `eyJ`), so a key can hide under an innocent name. For any `eyJ` value you find, decode the middle segment; the `anon` key says `"role":"anon"`, the dangerous one says `"role":"service_role"`. If you find a secret key, move the call into an Edge Function, then rotate the key, because it has already shipped to browsers. [Supabase service role key](https://tuvio.dev/blog/supabase-service-role-key) covers the rotation.

### 3. Secrets live in Edge Function secrets

Stripe, OpenAI, Resend and every other private key belong in server-side code. In Lovable Cloud, add them under Secrets; Lovable's docs note that secrets are write-only and that it rejects any name starting with `VITE_`. With your own Supabase project:

```bash
supabase secrets set STRIPE_SECRET_KEY=sk_live_...
```

Then read it inside the function with `Deno.env.get('STRIPE_SECRET_KEY')`, as [Supabase's Edge Function secrets guide](https://supabase.com/docs/guides/functions/secrets) shows. One more rule from Lovable's [security best practices](https://docs.lovable.dev/tips-tricks/security-best-practices): a function that uses the service role bypasses RLS, so it must check who is calling before it reads or writes anything.

### 4. Auth settings: email confirmation and open sign-ups

In Lovable Cloud, open **More → Cloud → Users → Auth settings**. In Supabase, it is **Authentication → Sign In / Providers**.

- Turn **Auto-confirm email** off (in Supabase: **Confirm email** on). Lovable's [email auth docs](https://docs.lovable.dev/features/email-auth) put it plainly: without confirmation, anyone can sign up with an address they don't own.
- If the app is invite-only or internal, disable sign-ups. Any policy that trusts "signed in" is only as strict as your sign-up page.
- Turn on leaked-password protection if it is off (in Cloud, the **Password HIBP check**). The Quick scan checks for it.

### 5. Storage bucket policies

A public bucket serves every file to anyone with the URL. For Cloud projects, Lovable's [storage docs](https://docs.lovable.dev/features/storage) say buckets are private by default and public buckets are blocked by a workspace setting. Check what you have anyway, and on your own Supabase project check the bucket list first. List the storage policies:

```sql
select policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'storage'
  and tablename = 'objects';
```

Look for upload, update or delete policies with no user check. A per-user folder policy, following [Supabase's storage access control guide](https://supabase.com/docs/guides/storage/security/access-control), looks like this:

```sql
create policy "Users upload to their own folder"
on storage.objects for insert
to authenticated
with check (
  bucket_id = 'avatars'
  and (storage.foldername(name))[1] = (select auth.jwt()->>'sub')
);
```

### 6. Read the generated migrations

Every table and policy Lovable created is written down. Lovable's [database docs](https://docs.lovable.dev/features/database) say each change is recorded as a migration file in your project's code: under `drizzle/migrations/` on newer Cloud projects, and under `supabase/migrations/` on earlier projects and on projects connected to your own Supabase. With GitHub sync on, those `.sql` files sit in your repository. Grep them:

```bash
grep -rniE "(using|with check)[[:space:]]*\([[:space:]]*true[[:space:]]*\)|disable row level security|user_metadata|security definer" --include="*.sql" .
```

Each match deserves a look. `security definer` is not wrong by itself, but such a function should set `search_path`. Lovable's own pre-publish list includes "new tables are not missing policies", so read the newest files first.

If you'd rather not read 40 migration files, a [free scan](https://tuvio.dev/scan) of the GitHub repo flags these shapes in them: policies open to anyone (`using (true)` or `with check (true)`, including `to authenticated`), policies open to any logged-in user, RLS disabled on a table, policies that trust `user_metadata`, and `security definer` functions without a `search_path`. It reads the `.sql` files in the repo, not your deployed database, so a policy added only in the dashboard won't be seen, and a table that is public on purpose gets flagged too. It needs no account.

## Is Lovable data safe? The short checklist

1. Two-factor authentication on your Lovable account.
2. Rotate any real key you ever pasted into a project chat that was public.
3. Run the Deep scan and read every finding.
4. Zero tables with RLS off; zero `using (true)` policies on private data.
5. No `service_role` or `sb_secret_` value in `src/` or `.env`.
6. Private keys only in Edge Function secrets, and every function checks its caller.
7. Email confirmation on; sign-ups closed if the app isn't public.
8. Storage writes tied to the user who owns the file.
9. Migrations read, newest first.

So how safe is Lovable? It is a reasonable place to build. The app is safe for production when the database says no to the right people, and that is something you can check in an evening. For the rest of the launch list, from webhooks to backups, see the [vibe coding security checklist](https://tuvio.dev/blog/vibe-coding-security-checklist).