Thousands ofLovable appswere leakingcustomer data
A Hamburg security firm checked 159,041 apps built with Lovable and found passport numbers, payment details and 200,000 chat messages open to anyone who looked.
Crissy Field, a security firm in Hamburg, wanted to know whether apps built with Lovable were leaving personal data open to anyone who hadn’t logged in. Lovable, if you’ve not come across it, turns a written description into a working web app without you touching any code.
They worked with Handelsblatt, which ran the story at the start of November. The paper says more than 50 million projects have been built with Lovable, with another 1.2 million every week. Lovable’s response was that it’s a problem across the industry.
Crissy Field has since published its own report with updated figures, and both the researcher and Lovable’s Head of Security have been answering questions about it on Y Combinator’s forum.
Drawn from Common Crawl between December 2025 and September 2026. Crissy Field tested the ones using Supabase, not Lovable’s own built-in database, so the bars below track those 34,545 apps.
used Supabase for their database, the group Crissy Field examined.
100% of Supabase appssent database records as soon as the page loaded, before anyone had logged in. Crissy Field tested these further.
71.4%returned email addresses across 10,560 tables when the researchers sent further read-only requests (30% of the 24,664 tested closely).
21.4%held data that a model the researchers ran rated as privacy-sensitive, according to the researcher.
Sending data when a page loads is normal. A restaurant’s menu is meant to be public. The trouble was how much else came back when the researchers sent a few read-only requests of their own, using the same key the page had already handed them.
No clever exploit was involved. The researcher says anyone with a moderate understanding of how the web works could reproduce it. The team had planned to try more sophisticated attacks afterwards and never got round to it, because so much sensitive data was already sitting in the open.
Crissy Field isn’t publishing the exact steps, because that would make it easy to copy. Lovable wires up databases in recurring patterns, the report warns, so an approach that pulls data from one misconfigured app works against others with little extra effort.
It’s not the first warning either. Back in March 2025, Matt Palmer found that 170 of the 1,645 apps on Lovable’s Launched list had database tables anyone could read or change.
What was in the tables
Crissy Field didn’t name the affected sites. These are some of the examples its report describes.
identity document records from one service provider.
profiles on a German lifestyle forum, plus more than 200,000 chat messages.
of ticket and food sales from event organisers and restaurants.
emails sent to one provider’s customers.
of a property management company’s internal emails, about its tenants, owners and business partners.
Other content the researchers could reach included tens of thousands of contracts and invoices, personal photo albums and internal WhatsApp chats. Crissy Field says it couldn’t tell whether any of it had already been misused.
“The people sharing their PII usually don’t know that it’s Lovable.”
The researcher on Y Combinator’s forum, replying to a comment arguing users knew what they were getting into when they handed over personal data.
The default stack
Ask ChatGPT how to build a web app and you’ll usually get pointed at the same few tools. Lovable or something like it to build the app, Supabase for the database and Vercel to host it.
That’s not ideal. If you’re not a developer, it’s very easy to go wrong, and you won’t know you have, because the app works perfectly well while it’s leaking.
Vercel had nothing to do with these leaks, to be clear. I just think it’s overpriced for what you get. It’s riddled with gotchas and workarounds, mostly config limits you have to find a way round, and it charges for dozens of different types of usage, so it’s hard to know what your bill will be. ChatGPT still sends everyone there.
The weak point is how Supabase gets used. In a typical web app, your own server sits between the browser and the database and decides what each visitor is allowed to see. With Lovable and Supabase, the browser talks straight to Supabase using a project key that’s bundled into the page for anyone to read. What stops that key reading every row is a set of rules on each table called row-level security.
A typical web app
Lovable with Supabase
Leave row-level security off one table, or write a rule that’s too loose, and anyone with the page’s key can query that table directly.
Supabase tightened its defaults this year. From 30 May, it started rolling out a change so new projects don’t open new tables to the browser automatically, and on 30 October it extended that to new tables in older projects too. Tables created before then kept whatever access they already had, and any table you expose to the browser still relies on row-level security to keep one user out of another’s data.
The small print
“No, you don’t need to know how to code.”
AI Output
The Services may use artificial intelligence models to generate code, content, or other outputs (“AI Output”). AI Output may contain errors, inaccuracies, or other issues and should not be relied upon without independent review and testing. You are solely responsible for reviewing, validating, and using any AI Output, whether it is generated through:
- our Platform’s integrated AI;
- the AI Gateway (via Third-Party AI Providers); or
- any model or API that you connect to the Services.
Crissy Field calls it “a troubling gap between the promise of an easy-to-use, all-in-one service and the responsibilities customers are expected to take on.”
In the UK, the business running the app is the data controller under UK GDPR, so a leak like this is theirs to deal with. If personal data’s been exposed, they may need to report it to the ICO within 72 hours of finding out. The researcher’s point was that people who keep hearing software is solved “may simply have no idea that they could face substantial fines”.
Sockt, a tool within Raq.com that tracks what websites are built with, finds Lovable on 583 UK websites and 30,075 worldwide. That’s only sites with their own domain name, so apps still on a lovable.app address aren’t counted.
It’s early
Lovable’s Head of Security, Igor Andriushchenko, replied on Y Combinator’s forum, saying the cause was weak row-level security, which Lovable’s scanner is built to catch, and that every app is scanned before it’s published. Andriushchenko also said many of the leaky apps came from older builds, and that “building an insecure app is much harder today than 6-12 months ago.”
When the scanner flags something you can press Fix, but many people don’t because they’re worried it’ll break their live app. Lovable can’t just fix everything automatically either. Across 10 million apps, Andriushchenko said, an auto-fix that worked 99% of the time would still break 100,000 of them.
Lovable’s security post from 10 November says you can turn on automatic fixes, and block anything with critical findings from going live. Both are settings you have to switch on. Since 12 November, apps on Lovable’s built-in backend ask you to review critical findings before publishing, though you can still publish anyway.
A block on publishing anything with critical issues is coming to every plan, and Lovable is looking at soft-blocking apps whose owners ignore warnings after a grace period.
There’s a view among developers that people can’t vibe code. I think that’s cope. It can be done. It’s just early, and at the moment it’s a bit of a wild west.
I build stuff with AI too, then get Alex, our CTO, to check it and fix it. We’ve reviewed a client’s Lovable app as well, and we run a free check for anyone who wants an outside look at theirs.
If you’ve built one
If your Lovable app stores anything about real people, these are the four things I’d check first.
- Open the live site in a private window without logging in, open your browser’s developer tools and watch Network as the page loads. If customer rows show up there, anyone can read them. Even if the homepage looks clean, remember your Supabase URL and public key are still in the page’s code, so any table left open can be queried directly.
- In Supabase, check that every table holding user data has row-level security switched on, with rules covering read, insert, update and delete. Keep files with personal data in a private storage bucket, because anyone with the link can download from a public one. Test while logged out and again logged in as a second test account, since a rule that lets any signed-in user read everyone else’s rows is nearly as bad. Make sure no secret keys, including Supabase’s service-role key, are in the app’s frontend code.
- Run Lovable’s deep security scan manually (it only runs on its own on Enterprise, and the quick check when you publish isn’t the same thing), then run it again after big changes. In your settings, switch on publish blocking for critical findings so a later prompt doesn’t quietly reopen a table.
- If personal data has already been sitting open, lock down the affected tables or take the app offline first. Rotating Supabase’s public key on its own won’t stop a leak, because the new public key goes straight back into your site’s code. Rotate any secret keys that were exposed, work out whose data was reachable, and check whether you need to tell the ICO within 72 hours.
