# Is Lovable safe for production?

Cyfendo · October 20, 2026

Lovable can run a production app. Whether a particular Lovable app is safe depends on the code and database rules generated for it, and Lovable treats those as the app owner's responsibility. In most Lovable apps the deciding factor is the Supabase database: the browser reads and writes it directly using a public key, and row-level security (RLS) policies are the only thing limiting what that key can reach.

## CVE-2025-48757

In March 2025, researcher Matt Palmer found that Linkable, an app built with Lovable, returned its whole `users` table in response to a modified request. He went on to check the public pages of 1,645 Lovable-built apps and found 303 exposed endpoints across 170 of them, about 10%. In the affected apps, tables of users and transactions could be read with the public key and no sign-in. One app's database function returned its Gemini API key to anyone who called it, and some apps accepted requests that changed an order's payment status. Palmer only tested what was reachable without signing in.

The problem was published in late May 2025 as CVE-2025-48757, with a CVSS score of 9.3. The entry in the US National Vulnerability Database notes that Lovable disputes it, on the grounds that each customer is responsible for protecting their own app's data.

No platform update could fix the affected apps, because the faulty part was each app's own policies. An app generated today can still end up with the same gap.

## Other problems that show up in Lovable apps

- A Supabase secret key (`sb_secret_...`) or legacy `service_role` key in front-end code. Either one bypasses RLS entirely.
- Edge functions that take a user ID from the request body rather than from the signed-in session, so a caller can act as any user.
- Orders marked as paid because the browser reported success, rather than because the payment provider's signed webhook confirmed it.
- Private files stored in a public bucket.

## What Lovable checks

According to [Lovable's security documentation](https://docs.lovable.dev/features/security) (October 2026):

- A quick scan runs when you open the publish dialog. It looks for tables without RLS, policies that allow everyone, leaked-password protection being off, critical vulnerabilities in npm packages, and MCP servers exposed without sign-in.
- A deep scan, which you start from the Security view, reviews the codebase for access control problems, unauthenticated endpoints, injection, leaked secrets, payment and authentication issues, and exposure of personal data.
- Findings don't block publishing unless a workspace admin turns blocking on.
- Wiz (static and dependency analysis) and Aikido (AI penetration testing) are available as paid integrations.

The same page states that these tools cannot guarantee complete security, and recommends an additional professional review for apps that handle sensitive data.

## Where scans fall short

Scans read code and configuration. They reliably catch a table with RLS switched off. They are less reliable with policies that exist but allow too much. A policy written as `auth.role() = 'authenticated'` limits a table to signed-in users, and since anyone can sign up, every account can then read every row. Some scanners flag this pattern and some don't. Signing in as a second user and requesting the first user's rows gives a definite answer.

Timing is the other gap. The quick scan runs at publish time and the deep scan runs when someone starts it, while Lovable's agent may change data access many times in between.

## A ten-minute check

1. In the Supabase SQL editor, list the tables without RLS:

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

2. Signed out, request a table using only the publishable key:

   ```bash
   curl "https://YOUR-PROJECT.supabase.co/rest/v1/users?select=*" \
     -H "apikey: YOUR_PUBLISHABLE_KEY"
   ```

   An empty list or a permission error means the table is protected. Rows mean it is exposed.
3. Sign in as a second test account and try to read and change the first account's rows.
4. Call each function under `/rest/v1/rpc/` without signing in and check what it returns.
5. Run Lovable's deep scan and work through its findings.

Fixes for each of these are in our [launch checklist for Lovable apps](/blog/how-to-secure-a-lovable-app).

## How Cyfendo checks a Lovable app

Cyfendo connects to Lovable as an MCP connector. When a task changes sign-in, data access, Supabase policies, payments, uploads or secrets, Lovable's agent sends the changed files to Cyfendo. Cyfendo starts a stand-in Supabase from the project's migration files, creates two test users, and runs steps 2 and 3 above: it requests rows with only the public key, and requests one user's rows while signed in as the other. Issues it reproduces are returned to the chat with fix steps. Policies it can't parse are treated as denying access, which means it can miss a leak hidden in a complex policy, but it won't report one it hasn't reproduced.

Setup takes about two minutes: see the [Lovable setup guide](/docs/integration/lovable).

Source: https://cyfendo.com/blog/is-lovable-safe-for-production