Is your Lovable app safe to charge people money?
Lovable builds you a working app in minutes and wires it straight into Supabase, which is exactly where the dangerous mistakes hide. CVE-2025-48757 is the proof: a researcher scanned 1,645 live Lovable apps and found 170 with databases anyone could read, no login needed. The usual culprits are row-level security left off, API keys shipped to the browser, and logins with no real lock on the door. Veilguard scans your live Lovable app the way an attacker would, grades it A to F, and hands you the exact fix for every issue.
The mistake that exposed 170 Lovable apps
Lovable defaults to Supabase, and Supabase protects your data with row-level security (RLS). When RLS is off, or a policy is written as USING(true), the public anon key that ships in your app can read and write every row in the table. That key is meant to be public; the protection is supposed to come from RLS. Skip it and your customer list is one request away.
This is not a rare edge case. In CVE-2025-48757, researcher Matt Palmer scanned 1,645 live Lovable apps and found 170 (about 10%) with databases anyone could read across 303 endpoints. The apps worked perfectly for their owners, who were logged in, and were wide open to everyone else.
Where a Lovable app usually leaks
- RLS off or too broad: the anon key reads and writes every table. The single most damaging Lovable issue.
- Secret keys in the browser: a Supabase service_role, Stripe, or OpenAI key bundled into the client, copyable from your page source.
- Auth or paywall checked in the browser: a check the visitor can flip in the console.
- Public storage buckets: uploaded IDs, invoices, and photos left crawlable by anyone.
- Wide-open CORS: any website allowed to call your API on behalf of your users.
Turn on row-level security: the exact policy
For every table that holds user data, enable RLS and add a policy that scopes each user to their own rows. Run this in the Supabase SQL editor, once per table, replacing the table and column names with yours.
-- 1. Turn RLS on for the table
alter table public.profiles enable row level security;
-- 2. Let each user read only their own rows
create policy "Users read own rows"
on public.profiles for select
using (auth.uid() = user_id);
-- 3. Let each user write only their own rows
create policy "Users write own rows"
on public.profiles for insert
with check (auth.uid() = user_id);Lock down the rest of your Lovable app
- 1.Enable RLS on every table, then confirm the Supabase dashboard shows no table marked "RLS disabled".
- 2.Move every secret key out of the browser to a Supabase Edge Function or server route, then rotate any key that was ever in the client.
- 3.Run auth and paywall checks on the server, from the verified session, never from a value in the browser.
- 4.Make storage buckets private and serve files through signed URLs.
- 5.Re-scan after each new feature, new tables and endpoints are where the next hole appears.
Scan your live Lovable app
Paste your app’s URL into Veilguard and it probes your deployed app the way an attacker would, trying to read your tables with the public key, no code access needed. For the deepest read, connect Supabase or GitHub read-only; your source is never stored. Either way you get an A to F grade and, for each issue, the exact SQL or a prompt to paste back into Lovable.
Frequently asked
Is my Lovable app secure by default?
No. Lovable is built to make your app work, not to lock it down, and it does not tell you what it left open. The most common critical issue is Supabase row-level security left off, which exposed 170+ live apps in CVE-2025-48757.
Do I need row-level security if I only use the anon key?
Yes, especially then. The anon key is designed to be public and ship in the browser; row-level security is the only thing standing between that key and your data. With RLS off, the anon key can read and write every table.
Do I have to connect my Lovable project?
No. The free scan looks at your live app from the outside, what an attacker already sees. For a deeper audit you can optionally connect Supabase or GitHub with read-only access, and your source is never stored.
I’m not technical, can I actually fix what it finds?
Yes. Every fix is either copy-paste code and SQL, or a ready-made prompt you hand straight to Lovable to apply for you. You do not need to read the code.
