Lovable builds a front end that queries your Supabase database straight from the user's browser, using what's called the anon key. That key is public by design — you can find it in the page source of any Lovable app in a few seconds. It isn't a secret and it was never meant to be one.
What keeps your data private is Row Level Security: rules on each table that say who is allowed to read or change which rows. The AI wires up the database correctly and the app works perfectly, so nothing looks wrong. But unless RLS is switched on and written properly for every table, the public key is enough for anyone to query it directly — bypassing your login screen entirely, because the login screen only exists in the browser.
That's the trap: the app looks completely fine from the outside. Sign-in works, data appears for the right users, and nothing errors. The hole is invisible until someone goes looking.
The important part isn't the CVE itself — it's the pattern. Any app that queries a database from the browser and relies on RLS has the same failure mode, whether it was built with Lovable, Bolt, v0, Cursor or by hand. The platform has since added checks and warnings, but your app's RLS policies are still yours to get right, and a warning you clicked past six weeks ago doesn't protect anything.
In April 2026 a separate problem surfaced, this time in Lovable's own platform rather than in generated apps. A Broken Object Level Authorization flaw meant any authenticated free-tier user could reach other users' public projects — including source code and database credentials — reportedly in about five API calls. It was live from 3 February to 20 April 2026, roughly two and a half months, and was found by an outside security researcher, not by the platform. Lovable shipped a fix within two hours of the public report, made existing public projects private, and has published its own account of what happened. Private projects and Lovable Cloud were not affected.
What to do if your project was public in that window: assume the credentials in it were readable and rotate them — Supabase keys, any API keys in the project, and anything in your environment variables. Then re-check your RLS policies, because an exposed database URL plus an exposed key is exactly the combination the first section of this page is about.
The wider lesson isn't that Lovable is careless — every platform ships bugs, and a two-hour fix and a public post-mortem is a better response than most. It's that a platform's own security tooling did not detect a flaw in the platform itself for over two months. That's not negligence, it's structural: nobody reliably audits their own work. It's the same reason accounts get audited externally, and the reason an independent check is worth running even when the built-in scan says green.
supabase.co. You'll see a project URL and a long anon key. If you can see them, so can anyone else — that part is normal.https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&apikey=YOUR_ANON_KEYTry the obvious table names:
users, profiles, orders, messages, subscribers.[] or a permission error means RLS is doing its job on that table. If you see real rows, that table is readable by anyone on the internet, right now.user_id equals their own id". Turning RLS on without adding a policy blocks everything, including your app — so do both together.If you have access to the Supabase SQL editor, this lists every table and whether RLS is switched on — more reliable than guessing table names:
select tablename, rowsecurity from pg_tables where schemaname = 'public';
Anything showing rowsecurity = false is open to the public key. Then check that each enabled table actually has a policy — RLS enabled with zero policies blocks everything, which is safe but breaks your app, and people often turn it back off in frustration rather than adding the policy.
service_role, sk_live_ and sk_test_. The service-role key bypasses every RLS policy you just wrote. If it's in your bundle, rotate it immediately and move that work into an Edge Function.localhost and not *.If reading that made you uneasy, that's the correct reaction — and it's exactly why we built an automated version. Broid's free scan performs this check for you, using only your app's own public key, and counts rows without ever reading their contents.
Being straight about the limits, because plenty of tools aren't: an external scan tests what your app exposes to the internet. It will find readable tables, leaked keys, unprotected endpoints and missing protections — the things that actually cause the incidents you read about in AI-built apps.
It cannot see your backend logic, and it does not log in, so it won't tell you whether one signed-in user can read another signed-in user's data through your app's own interface. It also can't judge whether your business rules are right. A clean result means "nothing dangerous is exposed publicly", not "this application is secure". Anyone who tells you a scan proves the second thing is selling you something.
It's the right question, and the honest answer is that it depends entirely on what the scanner does with it — so here is exactly what ours does, and you can verify every line of it from your own server logs.
anon key already sitting in your page source, visible to every visitor. We don't ask for, and can't use, a service-role key, a database password or a login.The stronger point: everything we do, an attacker can already do, and without asking. Your anon key is public, your endpoints are public, your bundle is public. A scan doesn't create the exposure — it tells you whether it exists before someone less friendly checks. And if you'd rather not involve anyone at all, the manual steps above genuinely work; we published them for that reason.
The caution is still worth applying to tools that don't say what they do. Ask any scanner these questions: which key do you use, do you read data or count it, do you write anything, and do you keep my report. If the answers aren't published, that's your answer.
Lovable added pre-publish security checks that flag issues such as disabled Row Level Security, and they help. But a platform reviewing its own output is marking its own homework, warnings are easy to click past, and the policies themselves are still yours to write correctly. An independent check is worth running for the same reason you don't proofread your own writing.
Yes. The anon key is designed to be visible in the browser and is not a secret. What matters is that Row Level Security decides what that key is allowed to do. The danger isn't the key being public — it's the key being powerful.
No. In a Lovable app the login screen lives in the browser, and the database is queried directly from the browser. Anyone can query the database without ever loading your login screen. Access control has to be enforced in the database through RLS, not in the interface.
The specific CVE relates to Lovable's behaviour up to 15 April 2025, and the platform has improved since. The underlying pattern hasn't changed: your app still queries the database from the browser with a public key, so your RLS policies are still what protect you. Check rather than assume.
Nothing to get a grade. Broid scans any URL free and returns an A–F security grade in seconds, including the live database-exposure test. A full report with plain-English explanations and a copy-paste fix prompt for each finding costs one credit, from $5 for five.
Yes, and you should know how. The SQL query above lists every table and whether Row Level Security is on; DevTools shows you whether a service-role key is in your bundle; two test accounts and curl will tell you whether one user can read another's data. There are also CI-friendly npm tools that introspect your schema. A scanner is faster and repeatable, not magic — anyone who implies otherwise is selling.
Fix it before anything else. Enable Row Level Security on that table and add a policy restricting rows to their owner, then re-test to confirm the data is no longer readable. If real user data was exposed, check whether your jurisdiction requires you to notify affected users — in Singapore that's the PDPA, in the EU the GDPR.
Paste your URL and get an A–F grade in seconds, including the live database-exposure test described above.
Scan my app freeBroid is independent — we don't build apps, so we have no reason to tell you yours is fine.