On 14 November a study by Crissy Field, a German firm, was on the front page of Hacker News. They looked at 159,041 Lovable projects found in the Common Crawl web archive. 34,545 of them used Supabase, and 24,664 of those sent database records as soon as the page loaded. On 7,403 of the 24,664, they could read tables with email addresses without signing in. They say themselves that this is not a confirmed leak rate, since some of those addresses may be public contacts or test data. The cases they describe include more than 200,000 private chat messages and more than 1,000 records with passport details. You can read it here.
Their study looked at live sites from the outside. Earlier this month I did the opposite, on a much smaller scale: I read the code of six Lovable apps and tried nothing against them. Reading the code shows the rule behind a readable table, and it also finds problems that a look from the outside cannot see, such as a user who can give themselves a paid plan.
You built an app with Lovable. It has sign-in, a database and maybe a paid plan. It works, and people use it. What the screen cannot tell you is whether a stranger can read your users' data, or run up your AI bill, without ever signing in.
In an earlier post I wrote that a cleanup does not find security problems, and that finding them is a different job. Enough founders need that job that I built a check for it. Before selling it, I ran it on six real apps. It failed. This post is about what it missed and what it finds now.
The six apps
They are six public apps built with Lovable on Supabase, with their code open on GitHub. I read the code and its history and nothing else. I ran nothing, signed in to nothing and tried nothing against a live app. I am not naming the apps, and I left out every detail that would point to one of them.
The first version failed
The first version looked for the classic things: keys left in the code, keys that were deleted but are still in the history, risky code patterns, and tables with no access rules. It passed its own tests. After I fixed three false alarms, it gave sensible results on five open-source developer projects.
On the six Lovable apps it was wrong in both directions.
It raised its loudest alarm, "Fix now", on a settings file in three of the six. That file holds only values that every visitor's browser receives anyway, and Lovable projects commonly commit it. I wrote about that file here. It also flagged the same chart component, which comes from a widely used UI kit, in five of the six.
And it did not raise one of the real problems. The closest it came was a line of background information saying that a table can be read by everyone, without noticing what was in the table.
Where the problems really were
None of the six had a leaked secret key. The check read 1,015 commits of history across them and found none. The thing people warn about most was not there.
The problems were in two places the first version barely read: the database rules, and the small server functions that these apps use for things like AI calls and email.
So I rebuilt the check around those two. It now reads the database files in order, down to the rules the app ends up with, because a rule written in one file is often dropped or replaced in a later one. And it reads every server function to see whether it ever asks who is calling.
What the second version found
Five of the six apps had findings a founder would want to know about. I confirmed the main findings by reading the code myself.
Private data behind a rule that asks nothing of the caller. Two apps have a rule that lets anyone, signed in or not, read every row of a table that holds something private. In one it is every user's email address. In the other it is a table of API keys.
Users who can upgrade themselves. In one app, each user may edit their own profile row, and that same row holds their subscription tier. A row rule covers the whole row, every column in it, so nothing in the code stops a user from setting their own plan from the browser. The table that counts their usage is theirs to edit too.
Server functions that never look at who is calling. There are 16 of them across four apps. Four, in two apps, have the platform's token check switched off, so anyone on the internet can call them. For the other twelve the platform only checks that a key or token was sent, and the public key that every visitor's browser has passes that check, whether it is the older anon key or the newer publishable key. At least nine of the 16 use a paid AI or email key, so a stranger can run them on the owner's account. Two take the user's id from the request itself and then work with the key that skips every database rule. A caller can read or change another user's data through them.
Rules that are not in the code at all. In two apps, some or all of the tables were created outside the repository, so no file says who may read them. The check cannot judge those. Its report prints one read-only query for the owner to run instead.
Each of the six also had between 25 and 32 packages with a published vulnerability, and none that is known to be malicious. That sounds worse than it is. It does not mean the app can be attacked through them, and updating the package is the usual fix.
The sixth app had nothing to fix and nothing to check, only notes. I read its rules by hand and agreed.
The owners of three of the apps have the details from me, sent privately before this post.
Three things you can look at today
- Rows a user owns. If the row a user may edit also holds their plan, role or credits, they can change those as well.
- Server functions. Open each one and look for the line that checks who the caller is. If a function uses a paid key or the service role key and has no such line, treat it as open to everyone.
- Tables made in the dashboard. Run this in the Supabase SQL editor. It only reads.
select schemaname, tablename, rowsecurity from pg_tables where schemaname = 'public' order by tablename; A table with rowsecurity = false has no rules at all. Anyone who has your public key can usually read and change it, and that key is in every visitor's browser. Supabase has been changing this during 2026 so that new tables cannot be reached until you grant access, but tables that already existed keep the access they had.
What this does not tell you
Six apps is a small sample next to the study above, and all six are apps whose code is public. I would not turn "five of six" into a claim about every Lovable app.
I read code. I did not test whether any of this can be used against the running apps, and their live settings may differ from the files. Newer Supabase projects, for example, are stricter by default about what a visitor can reach.
The check looks for a fixed list of problems. It cannot see settings that were changed by hand in a dashboard, or mistakes in the logic of the app, such as one customer being able to open another customer's order. An empty report means these problems were not found. It does not mean the app is secure, and the report says so in bold at the top.
I have not yet run it on Bolt, Next.js or Firebase apps.
If you want it run on your app
The check is an option with the scan on my Upwork listing. The scan costs $95, and the security check adds one day and $50. That is an opening price for the first five clients. After that it is $150. You give read access to the repository. You get a report with the file and line of each finding, sorted into fix now, check and information. The report ends with a fixed price for fixing what it found. Fixing it is a separate order: up to three findings cost $300. If you then hire me for a cleanup, the $95 for the scan comes off its price. Nothing is run against your live app, and no key is ever tried.
