Short answer: Lovable is safe to build with, but that does not mean your Lovable app is safe. Those are two different questions, and almost everyone conflates them. The platform is legitimate and its own infrastructure is not where things go wrong. What goes wrong is the app Lovable generates for you, because it ships working but not locked. The AI reliably builds the feature and reliably skips the settings that keep your data private.
This is not a knock on Lovable specifically. It is true of every AI builder that provisions a database and an auth screen for you. But Lovable is the one with a named CVE and a documented set of leaks, so it is the clearest place to see the pattern. Let us walk through what is actually true.
What Lovable does well
Credit where it is due. Lovable ships apps on solid infrastructure (Supabase, modern hosting), the anon key it puts in your browser is supposed to be public and is not itself a vulnerability, and Lovable now runs an automatic security scan when you publish that catches some misconfigurations in 10 to 15 seconds. None of that is the problem. If you do the three things below, a Lovable app can be perfectly safe.
Scan your own app for issues like these
Paste your live URL. We check what your app serves publicly for exposed keys and misconfigurations. No account, no install.
The three gaps that make a Lovable app unsafe
Every serious exposure we find in Lovable apps comes down to one of three settings the generator does not turn on for you. They are not exotic. They are the three most boring, most skippable steps in shipping an app, which is exactly why they get skipped.
| The gap | What it means | What a stranger can do |
|---|---|---|
| Missing Row Level Security | Your Supabase tables have no rule saying who can read which rows, so the public anon key can read all of them. | Open your app, grab the public key from the browser, and read your entire users or orders table with no login. |
| Exposed secret keys | A real secret (Stripe sk_live, OpenAI sk-, or the Supabase service role key) ended up in the browser bundle, not just the public one. | Copy the key out of your JavaScript and use it to charge cards, drain your API credits, or bypass every database rule. |
| Broken access control | A private page or API endpoint renders to anyone because the only check is the login screen, not the route itself. | Type /dashboard or hit /api/users in a logged-out tab and see the private view or the raw data. |
The first two are about your database and your keys. The third is the one most people do not even know to check, and it is the most common serious issue we find across AI-built apps in general. We wrote up the data on it in our study of 2,736 live apps.
The CVE that made this real: CVE-2025-48757
This is not theoretical. In 2025, security researcher Matt Palmer found that 170+ Lovable apps across 303 endpoints were leaking data because Row Level Security was missing or misconfigured on their Supabase backends. Using nothing but the app's own public anon key, anyone could read tables directly with no login. The exposed data included emails, phone numbers, payment and subscription status, API keys, and developer credentials.
Palmer reported it privately in March 2025, a public exploit appeared in April, and after the disclosure window passed without a full fix it was published as CVE-2025-48757. The important part for you is the root cause: it was not a Lovable platform bug. It was 170+ individual apps that shipped without the database rules that decide who can read what. Every one of those owners almost certainly believed their app was safe because it had a login screen.
What our own scans show
We ran the same kind of anonymous, read-only check across a broad set of live AI-built apps, not just Lovable, to see how common this really is. Of 2,736 apps, 124 (about 1 in 22) served private surface to a logged-out visitor: 89 had an unprotected dashboard or account page, 25 had an API returning data with no token, and 10 had an openly readable database. That is the broken-access-control class specifically, and it lines up exactly with what the Lovable CVE exposed at scale. The full breakdown is in the unprotected-dashboard study, and the database-specific version is in how many AI apps leave their database open.
How to check your own Lovable app
You do not have to guess which side of this your app is on, and you do not have to trust the platform's own scan to be the last word. Paste your app's URL into Prbl. It does what an outside visitor's browser can already do: requests your private routes with no session, hits your API with no token, and checks whether your Supabase tables answer the public key. It takes about 30 seconds, needs no account for the scan, and tells you exactly which of the three gaps your app has, if any.
If it finds something: the fix
The three fixes map directly to the three gaps:
- Turn on Row Level Security for every table and add owner-scoped policies so each user reads only their own rows. Walk through the Supabase RLS checklist and confirm an anonymous read returns nothing.
- Get secrets out of the browser. Any real secret key belongs on the server, never in the client bundle. The public anon key is fine to ship; a
service_rolekey or a Stripesk_liveis not. - Add a real auth check to every private route and endpoint, not just the login screen. This is broken access control, and it is the one the login page hides.
Frequently asked questions
Is Lovable safe to use?
Yes. Lovable the platform is legitimate and its own infrastructure is not the problem. The risk is in the app it generates for you: by default the AI wires up a working app but does not turn on the access controls that keep your data private. So the honest answer is that Lovable is safe to build with, but whether your specific app is safe depends on three settings you have to confirm yourself. Most people never check them, which is exactly why so many live Lovable apps leak data.
What was the Lovable security vulnerability (CVE-2025-48757)?
In 2025, security researcher Matt Palmer found that 170+ Lovable apps across 303 endpoints were leaking data because Row Level Security was missing or misconfigured on their Supabase databases. Anyone could use the app's public anon key, which is meant to be public, to read tables directly with no login: emails, phone numbers, payment status, API keys, and developer credentials. It was assigned CVE-2025-48757. The root cause was not a Lovable bug. It was that the generated apps shipped without the database rules that decide who can read what.
Does Lovable's built-in security scan cover this?
Partly. Lovable added an automatic scan that checks database configuration and known misconfiguration patterns in about 10 to 15 seconds when you publish. It is a useful first pass, but it is detection focused on the platform's own checks. It does not do what an outside visitor's browser can do, which is actually request your private pages and endpoints with no login and see what comes back. That external, unauthenticated check is where real exposures show up, and it is what Prbl runs.
How do I check if my Lovable app is exposed?
Paste your app's URL into Prbl. It runs the same anonymous, read-only checks a stranger's browser could: whether your private routes render to a logged-out visitor, whether your API returns data without a token, and whether your Supabase tables are readable with the public key. It takes about 30 seconds, needs no account for the scan, and tells you exactly which of the three gaps, if any, your app has.
How do I fix an exposed Lovable app?
The three fixes are: turn on Row Level Security for every Supabase table and add owner-scoped policies so each user can only read their own rows; move any secret keys (Stripe, OpenAI, service role) out of the browser bundle and onto the server; and add an auth check to every private route and API endpoint, not just the login screen. Prbl gives you the exact step for each finding on your app.
The honest bottom line
Is Lovable safe? The platform, yes. Your app, only if you turned on the three things the AI left off. The good news is that checking takes about 30 seconds and the fixes are well understood. Scan your Lovable app and find out which side of this it is on before someone else does.