Lovable security: is Lovable safe, and what your app still needs

Is Lovable safe? The short answer

Yes for the platform, with conditions for your app. Lovable writes the code, hosts the app and runs the database for you, and it holds SOC 2 Type II, ISO 27001:2022 and AIUC-1 certifications. It is not HIPAA compliant and does not sign the business associate agreements HIPAA requires. What it cannot decide for you is who may read which rows, which values belong on a server, and what each function should refuse. Its security documentation says so plainly: you are responsible for making sure your app meets the security requirements of its use case, especially when it handles sensitive data.

Most public Lovable security issues are of that second kind. The best known, CVE-2025-48757, came from a scan of 1,645 Lovable apps in which 170 had missing or weak RLS. The platform itself has had one widely reported problem too, covered below. So the honest answer has two parts: what Lovable runs, and what you ship.

What Lovable is responsible for, and what you are

The stack Lovable builds, and where it leaks

Lovable apps created from May 13, 2026 (June 22, 2026 for Enterprise workspaces) use TanStack Start, which renders pages on the server. Older apps use React with Vite and render in the browser. There is no choice of framework. The data lives in PostgreSQL, either in Lovable's built-in backend, which its docs describe as built on Supabase's open-source foundation and enabled by default, or in a Supabase project you connect yourself. The built-in backend adds sign-in, file storage, realtime updates and edge functions: small server programs that run your AI features, emails and payments.

The browser talks to the database directly. The project URL and the public key sit in .env as VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY, are built into the JavaScript bundle and, per Lovable's docs, are safe to be public. Like the Supabase anon key it replaces, the publishable key gives every visitor the anon role. Your database policies are what stand between a stranger and your rows.

What Lovable's security scan catches, and what it does not

Lovable ships a real set of security tools, and it deserves credit for them. Here is what its documentation describes as of November 2026.

Two limits matter. First, Lovable states that its built-in scanners are static analysis: they read code and configuration and flag patterns that look risky. They do not send requests to your live app to see what comes back. Second, a scan only reports. In the February 2026 case below, Lovable said a scan had been offered before publishing and its recommendations were not applied. Its own docs add that these tools cannot guarantee complete security, and suggest a professional review for apps with sensitive data.

Lovable security issues: three public cases

CVE-2025-48757: missing RLS in 170 apps

In March 2025, researchers scanned the home pages of 1,645 apps listed on Lovable Launched, Lovable's showcase, and found 303 endpoints across 170 projects, about 10.3%, with inadequate RLS. Their write-up lists names, phone numbers, subscriptions, payment details and API keys among the exposed data, and notes that pages behind a login were not checked. NVD lists the CVE with a CVSS score of 9.3, assigned by MITRE, and records that Lovable disputes it because each customer is responsible for protecting their own app's data.

February 2026: one showcased app, 16 flaws

The Register reported that a researcher found 16 vulnerabilities, six of them critical, in a single app hosted on Lovable and featured on its Discover page, exposing 18,697 user records, many of them teachers and students. One of the main bugs was an access check in a database function written backwards: it blocked signed-in users and let anonymous visitors through. Lovable answered that its scan before publishing had made recommendations that were not applied, that the project included code not generated by Lovable, and that the vulnerable database was not hosted by Lovable. A check that RLS is on does not see a logic bug like this one; a code review or one request from outside does.

April 2026: public projects' chats and code

The Register also reported a researcher's claim that any free account could read other users' chat history and source code on public projects, including database credentials found in that code. Lovable first said it had not suffered a data breach, and that the code of public projects is visible by design. It then explained that projects have been private by default on every plan since December 2025, and that a February 2026 change to its permission system had accidentally re-enabled access to chats on public projects, which it reverted.

How to check your Lovable app

Six checks, from the cheapest to the most telling. The first four happen inside Lovable and change nothing.

1. 1

   Run both scans

   Open the project's Security view and run the Deep scan, not only the Quick scan you get on publish. Read every finding, including the ones marked ignored, and note which tables and functions they name.

2. 2

   Read your policies

   Go to More → Database → Manage → Policies. The view is read-only. Look for policies that apply to anon, rules with no condition, and policies for authenticated whose expression never mentions auth.uid(). Each of those lets in more people than you probably meant.

3. 3

   Query the database

   Open More → Database → Manage → SQL editor and run the queries below. They read the system catalog of your own project and change nothing.

4. 4

   Search the code for secret keys

   In the code editor or your synced Git repository, search for sk_live_, sk-, service_role, sb_secret_ and PRIVATE KEY. The .env file should hold only public values such as VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY. A Supabase key written as a JWT (a long string starting with eyJ) hides its role, so paste it into the Supabase key checker; the API key leak checker recognises other common key formats.

5. 5

   Use the app as a stranger

   Open the published app in a private window, signed out, and try every page and form. Then sign up with a second account and try to open the first account's records, for example by changing an id in the address bar. If you see someone else's data, you have an IDOR.

6. 6

   Check visibility and members

   Confirm the project is private, and remove workspace members who no longer need access.

-- 1. Tables with RLS off, and what the public key may do there
select c.relname as table_name,
       has_table_privilege('anon', c.oid, 'select') as anon_select,
       has_table_privilege('anon', c.oid, 'insert') as anon_insert
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public'
  and c.relkind in ('r', 'p')
  and not c.relrowsecurity;

-- 2. Policies that let every caller through
select tablename, policyname, cmd, roles
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true');

-- 3. Functions anon can call, owner-privileged ones first
select p.proname as function_name,
       p.prosecdef as runs_as_owner,
       has_function_privilege('anon', p.oid, 'execute') as anon_can_call
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
  and p.prokind = 'f'
order by runs_as_owner desc, function_name;

Fixes, with prompts for Lovable

Lovable changes policies and functions through its chat, so the fastest fix is a precise prompt. Paste one at a time, then reopen the policies view to confirm what changed.

Lock every table

Enable row level security on every table in the public schema. For each table that stores user data, add policies so a signed-in user can only read, insert, update and delete rows where user_id equals auth.uid(). Add no policy for the anon role unless I name the table. Then list every policy you created or changed.

Compare what it wrote with the pattern below. The first two policies are the ones scans and attacks turn up most; the third is the fix.

-- Leaks: every visitor reads every profile
create policy "Profiles are viewable" on public.profiles
  for select using (true);

-- Leaks too: any stranger who signs up reads every profile
create policy "Signed-in users can view profiles" on public.profiles
  for select to authenticated using (true);

-- Fixed: each user reads only their own row
create policy "Users view their own profile" on public.profiles
  for select to authenticated using ((select auth.uid()) = user_id);

The Supabase RLS guide has policies for teams, shared records and public read with owner write. The RLS checker reviews the policies you paste, in your browser.

Protect edge functions

In every edge function that calls an AI model, sends email, or reads or changes user data, reject requests that do not carry a valid signed-in user session and return 401. Check that the user owns the record they ask for. Add a per-user rate limit to the AI functions.

An AI function that answers anyone runs up a bill you pay. See unprotected AI endpoints. For payments, ask Lovable to verify the Stripe-Signature header with the webhook signing secret before handling any event, as covered in Stripe webhook security.

Move secrets to the server

Find every API key or secret in the frontend code and in .env that is not meant to be public. Move each one to Secrets, read it only in an edge function or server code, and tell me which keys I must rotate at the provider.

Rotate at the provider, not only in Lovable: a key that shipped in a build has already been copied. Leaked API key: what to do gives the order of operations.

Check server code and storage

Review every server function and edge function that uses an admin or service role client. Before each read or write, check that the signed-in user owns the record. Make the uploads bucket private and add storage policies so each user can only read and write files in a folder named after their user id.

The service role key skips RLS by design, so any code holding it has to do the checking itself. The service role key guide explains when it belongs on a server and when finding it is a breach. For buckets, see Supabase storage security.

The traps after the first fix

• The Deep scan is a snapshot. It does not run as you work, and the Quick scan never reads code. A feature added after your last Deep scan has not been reviewed, so run it again before each publish that adds data or functions.
• New features rewrite policies. When a prompt asks for something the current policies block, loosening a policy is a common shortcut for any coding agent. Reopen the policies view after each feature that touches data.
• `.env` is committed on purpose. Lovable needs .env in the repository so builds get their VITE_ values. Anything you put there is in your Git history, and every VITE_ value your code uses ends up in the browser bundle.
• Your own Supabase project is your job. If you connected Supabase instead of the built-in backend, Lovable's password rotation does not cover it, and its keys and settings are yours to manage. The Supabase security guide covers that side.
• Only critical dependency flaws become findings. High-severity ones do not, and some critical ones are held back when Lovable judges them unable to affect its apps or unlikely to be exploited (they stay in the project's dependency list with a marker). Run npm audit on a synced copy from time to time.
• Auto-fix has limits. It picks up a few critical database and dependency findings from the Quick scan during your build requests, uses credits, and never fixes Deep scan findings. Fix those from the Security view or the chat, then reopen the policies view.

Test the published app, not only the code

Scans read what you wrote. An attack shows what your published app answers, which is exactly what a stranger gets. Lovable's own docs draw the same line and offer Aikido's pentests as an option. Keybrum runs this kind of test against the stack Lovable generates. It:

• reads, inserts and updates rows in every table it finds, as anon and as a freshly signed-up account;
• calls your RPC functions, lists and uploads to storage buckets, and subscribes to realtime channels;
• sends a short test prompt to edge functions that look like AI endpoints, to see whether a model answers without an account;
• looks for secret keys in your bundle and in table rows anyone can read;
• tries to open one account's records from a second account, and sends unsigned Stripe webhook events.

Each finding comes with the request that worked and the fix. A coding agent such as Cursor or Claude Code reads them through Keybrum's MCP server, or you paste the fix into Lovable's chat. Keybrum only attacks apps whose owner proved ownership, and on a plan it attacks again on every deploy, so a policy loosened next week shows up next week.

Lovable security checklist

• The project is private, and keys from any period when it was public have been rotated
• The Deep scan ran after the last feature that touched data, and every finding is fixed or explained
• Every table in public has RLS on, and no policy uses the condition true unless the data is meant to be public
• Policies for authenticated compare the row's owner to auth.uid()
• Functions that run as their owner cannot be called by anon, unless that is intended
• Buckets with private files are private, with per-user folder policies
• .env holds only public values; secret keys live in Secrets and were rotated if they ever shipped
• Edge functions that call AI, send email or change data require a signed-in user and have a rate limit
• Stripe webhooks verify the signature
• Leaked-password protection is on (built-in backend: More → Users → Settings → Email, Password HIBP check)
• A second test account cannot see the first account's data
• The published app was tested from outside after the last deploy

The vibe coding security checklist extends this list to other AI builders, and vibe coding security risks explains why the same bugs keep coming back.