Is Lovable safe? What 18,554 live Lovable apps showed

You built something on Lovable, it works, and you are about to put real people on it. Somewhere in that week you typed "is lovable safe" into a search box, and what came back was either a page about a 2025 security disclosure or a vendor selling you a scan. Neither one said anything about the app you are about to publish.

Here is what most of those answers get wrong: "is Lovable safe" is three questions wearing one sentence, and the one that decides whether strangers can read your users' data is the one almost nobody measures.

We can measure it. Between 12 and 14 August 2026 we ran the same nine external checks anyone can run free on our homepage over 30,998 live apps, and 18,554 of them were published on Lovable. That is the largest cohort we have, three in every five apps we have ever scanned. This is what came back for those, and where our view stops.

Is Lovable safe?

As a platform, yes, and by a wider margin than we expected. Lovable's own output was the cleanest of the five builders we measured. Everything that decided a grade was inside the app its owner had built.

Think of it as a shop with a stockroom across the street. Lovable builds the shop: the windows, the counter, the sign. Supabase owns the stockroom, and it has its own lock on its own door. What the shop hands a passer-by is one question. What the stockroom hands anyone who walks up and asks is a completely different one, and no amount of tidying the shop changes it.

1. The platform. Does Lovable publish your app properly: a valid certificate, a domain that will not lapse, nothing leaking from the build. This is the shop.
2. The agent. Is the code Lovable's AI writes sound. No scan from outside can see the wiring, and this post says so rather than guessing.
3. The app you published. What a stranger can reach from the pavement: a key in the code a browser downloads, a storage bucket that lists its files, a database table that answers anyone who asks.

Our checks read the third and two parts of the first. On the platform, the certificate was valid on all 18,486 apps where we could read one, and not one domain out of 18,554 was near expiry. On the agent we have nothing to measure. On the app, we have 18,554 answers.

What we found in 18,554 Lovable apps

Nine checks, run from outside, with no login and no access to anyone's account. We never read a row: where a database answered, we asked how many rows it would hand over and stopped there. No app is named here or anywhere else we publish. Every share below is of the apps that check answered on, because a check that could not finish is unknown rather than passed, and that rule is why the denominators move. The method and the data are in the report.

The grades: 15,963 A, 370 B, 1,814 C, 402 D and 5 F. Nine apps had no finding at all.

That first row is the reason "99% of Lovable apps have a security issue" is a sentence you will see somewhere and should ignore. Browser security headers are sent by whatever serves your page, which on yourapp.lovable.app is Lovable, which is why every app on that host gets the same answer. It is worth having and it is not what a D is made of.

Leave that row out and 15,453 of the 18,554 apps had nothing else at all. The remaining 3,092 are where the rest of this post lives.

What Lovable gets right, and it is most of the list

Three of the numbers above are the best we have recorded on any builder, and they are all decided by the platform rather than by you.

Source maps. 225 of 18,553 Lovable apps publish the original files behind the app, comments and all. That is about 1 in 80. On Base44 the same check fires on 59% of apps, and on Replit 6%. Lovable's production build does the right thing by default, so this one is mostly not your problem.

Cross-origin headers. Zero apps out of 18,518 told any website in the world that it may call their API, and zero allowed that with the visitor's login cookies attached. That is the finding most likely to let another site act as your user, and on Lovable it did not appear once.

Stray private files. Zero apps out of 18,442 served a .env or a .git/config from a plain URL. A Lovable app has no server of its own to misconfigure, so there is no file at the back to leave out.

None of that is faint praise. It is the part of the job you did not have to think about, and on most other builders somebody does.

The one number that matters: 2,017 of 3,553

Of the Lovable apps whose Supabase database we could actually ask, 57% handed rows to a request carrying no login at all.

The denominators are worth walking, because this is the number everybody quotes and almost nobody scopes. Of 18,554 Lovable apps, 6,532 named a Supabase project in the code they ship. Of those, 3,553 answered our request well enough for us to judge, and the other 2,979 did not, so they are unknown rather than clean. Of the 3,553, 2,017 returned rows to a stranger.

In 373 of those apps the table that answered was named after people: users, profiles, orders, messages. That is 373 apps, not 373 tables. In the other 1,644 it was something we could not name from outside, which may be a product catalogue that was always meant to be public or may be anything else.

Measured against every Lovable app we scanned rather than the subset we could judge, 2,017 out of 18,554 is about 11 in every 100. Hold onto that figure for two sections' time.

Why it lands on the database and not on Lovable

Because of a design decision that is correct, deliberate, and almost never explained to the person it affects.

A Lovable app has no server of its own. The page in the visitor's browser talks to Supabase directly, which is why the whole thing can be built in an afternoon and why so few of these apps have an open API route: there is no API of yours to leave open. For that to work, the address of your database and a key to it have to be printed inside the app, where anyone can read them. That key is the publishable key, and it being public is correct. It is supposed to be there.

Which means the only thing between a stranger and your users table is a per-table Supabase setting called Row Level Security. With it on and a policy written, the public key reads only the rows the policy allows. With it off, the public key reads the table.

Now the part that decides most Lovable projects. Supabase turns Row Level Security on by default for tables you create by clicking around in the Table Editor. Tables created by running SQL do not get it, and running SQL is how a builder creates tables for you. So the usual shape of a Lovable project is a few tables you made by hand, which are protected, sitting beside the ones that were generated for you, which may not be. Both look identical. Neither will complain. The app works perfectly either way, which is the whole problem: nothing you can see from the front tells you which kind you have.

The longer version of this, with the SQL, is here, and the plain-language walkthrough for this platform is is your Lovable app safe.

The policy that clears the error and leaves the table open

Turning Row Level Security on is step one of two, and the second step is where an AI assistant will helpfully do the wrong thing.

With the setting on and no policy written, your own app stops working. You get an error, you paste it into the chat, and something arrives that makes the error go away. Very often what arrives is a policy that permits everybody, written as using (true). It is a valid policy. It satisfies the requirement that a policy exist. It allows every row to every request.

The dashboard now reports the table as protected, the error is gone, your app works, and the table is exactly as readable as it was before. We have a whole article on this one because it is the single most convincing failure in the stack: RLS is on and your table is still public.

If you have ever pasted a row-level-security error into a chat window and accepted the first fix that made it build, go and read that policy today.

CVE-2025-48757, and why it is no longer your question

It is real, it was serious, and it has been closed on Lovable's side for over a year. It is also not the thing you should be checking for.

In May 2025 the security researcher Matt Palmer published CVE-2025-48757, covering Lovable apps whose Supabase tables had Row Level Security missing or written too permissively. He scanned 1,645 Lovable apps and found 170 with exposed databases. Lovable's response was to add a security check that runs before you publish and warns you about unprotected tables.

Here is the honest reading, and it is why the CVE is the wrong frame. That disclosure found roughly 10 exposed apps in every 100. Sixteen months later, on a cohort eleven times the size, we found about 11 in every 100. The denominators are not identical and neither sample is the whole internet, so treat the two as the same order of magnitude rather than as a precise comparison. The direction is clear enough: the rate did not fall.

That is not a fix that failed. It is a sign that this was never really a vulnerability in a product. It is a setting on your own tables, in your own Supabase project, which nobody else can turn on for you. A patch cannot reach it, which is exactly why a check you run yourself can.

What the 822 keys were actually made of

Almost all of them were fine, and a scanner that told you otherwise would be training you to ignore it.

822 of the 18,554 Lovable apps had something key-shaped in the code a visitor downloads. Read as a list of shapes that is 4% of apps "leaking secrets". Read as what each key can actually do, it looks like this:

The 727 Google keys are the reason we classify rather than match. A Google Maps key in a browser is where it is supposed to be, and the fix is restricting it to your own domain rather than panicking.

The bottom four rows are the ones that matter, and they are rare: 30 apps out of 18,554. They are also the findings that cost money on their own, and they usually surface as a bill arriving before anyone noticed. Two details worth recording. All three service_role keys in the entire 30,998-app sweep were in Lovable apps, and so were two of the three live Stripe secret keys. A service_role key in a browser makes every Row Level Security policy in your project irrelevant in one line, which is why it is the one finding we grade critical on sight and the one worth rotating the same day.

Telling the two kinds apart takes about a minute, and we wrote the guide.

The 768 storage buckets nobody meant to open

A Supabase bucket marked public does not only serve the files your app links to. It will also list every file in it to anyone who asks.

768 of the 16,565 Lovable apps we could check had at least one bucket that listed its contents. The reason this happens is the same as the reason tables end up readable: making a bucket public is how you get an image to appear, it works immediately, and nothing afterwards tells you that the listing came with it. Uploaded invoices, ID photos and user avatars all end up in the same place. What a public bucket actually exposes covers the fix, which is signed URLs rather than a private bucket you then cannot read from.

The five-minute check on your own Lovable app

Each one is a page you open. Use a private window so your own login does not answer for a stranger.

1. Supabase → Authentication → Policies. Read down the list. Any table showing Row Level Security disabled is readable by anyone with your project address, which is printed in your app.
2. Read the policies on the tables that do have it on. If one of them permits everybody, the table is open and the dashboard still calls it protected.
3. Supabase → Storage. Any bucket marked public lists its files to anyone. Check what is in it before deciding that is fine.
4. Supabase → Settings → API. Confirm the key your app ships is the publishable one. If a secret key has ever been pasted into the project, rotate it there before deleting it from the code, because the old value still works until you do.
5. Or let the scan do it. It runs those four from outside and five more, takes about 20 seconds, needs no account, and shows you a grade and what produced it: scan your app.

If you would rather work through the whole surface as a list, the 10-minute security checklist covers what is worth confirming on any newly launched app, and can anyone read your Supabase database is the test to run if you only do one thing.

Your app changes every time you publish

A scan you ran last month describes last month's app, and on Lovable that is a shorter month than most.

Publishing is one click, so a change is live the moment you accept it. There is no deploy step between you and the internet to catch a table that was added this morning with Row Level Security off, or a key pasted into the chat to get past a failing build at midnight. Every one of the 2,017 exposed databases we found belonged to somebody whose app was working fine.

Reeve Monitor is the version of this post that runs itself. It re-runs all nine checks every hour on up to three apps, watches whether the app is up every 60 seconds, tells you when a result changes rather than waiting for you to look, and sends a monthly report. It is $12 a month at list, with seven days free before it charges you; the pricing page is sometimes below the figure here and never above it.

If your Lovable app uses Supabase, and 6,532 of the 18,554 we scanned do, the other half of the problem is the copy. An exposed table is a thing a stranger can read. An agent with database access, or a migration that ran the wrong way, is a thing that can delete it, and Supabase's own daily backup on the free tier is not something you can restore from yourself. Reeve Care takes an encrypted copy of your Supabase database every night, keeps it somewhere your project cannot reach, verifies that each copy actually restores, and gives you a one-click restore when you need it. It includes everything Monitor does. Care is $49 a month at list for one app, with the same seven days free.

The shape of that second failure, told by someone it happened to, is the day an AI agent deleted a production database. Nothing in this article's nine checks would have helped there. A copy would have.

What to do this week

Lovable did its half well. The 2,017 is the half that is yours, and it is a setting rather than a rewrite. If you want the cross-builder comparison instead, which AI app builder is safest has the table for all five.