Your Lovable app may be showing strangers more than the page does
Researchers found personal data readable without a login on thousands of Lovable sites. Nobody hacked them; the database rules were missing or too loose. Here's how to check yours in an afternoon, and what to do if something's open.
Check your Lovable app's database rules now. Crissy Field reported on November 2, 2026 that among 24,664 Lovable sites sending Supabase data without a login, 7,403 had readable records containing email addresses. The cause was missing or loose Row Level Security, not a hack. Test your live app signed out and with two accounts, run the built-in scans, and get a professional review before it holds sensitive data.
What happened, in plain terms
If you built something on Lovable and it stores anything about real people, set aside an hour this week to check who can read it.
On Monday, the German business paper Handelsblatt reported on research from Crissy Field, an application security firm in Hamburg. Their full report is blunt. They looked at 159,041 Lovable projects found in the Common Crawl web archive between December 2025 and September 2026. Of those, 34,545 used Supabase as their database, and 24,664 sent Supabase records to the browser as soon as the page loaded, with no login at all.
That part can be fine. Plenty of data is meant to be public, like a menu or a product list. The trouble came next. With further read-only requests, the researchers found records containing email addresses in 10,560 tables across 7,403 of those sites, about 30%.
Some of what they found is hard to read. A German lifestyle forum exposed more than 80,000 profiles and more than 200,000 chat messages. Event organizers and restaurants exposed ticket and food sales with emails, phone numbers, addresses, payment information and ticket codes. One service provider exposed more than 1,000 records with passport numbers. There were contracts, invoices, photo albums and internal WhatsApp messages too.
Two fair caveats from the researchers themselves. The 30% figure "should therefore not be read as a confirmed data leak rate," and their sample isn't representative of every Lovable app. They also couldn't tell whether anyone misused the data, and they aren't publishing how they got in.
Nobody broke in. The door was set to open
This is the part worth understanding, because it applies well beyond Lovable.
Apps like these usually talk to the database straight from the visitor's browser. To do that, the page carries a public key. That key is supposed to be public. It isn't a password, and Supabase's guide to API keys says as much. What keeps strangers out is a set of rules inside the database called Row Level Security, or RLS. Each rule says who may read or change which rows.
When those rules are missing or too loose, the page itself might show only a signup form, while the database will happily answer a slightly different question from anyone who asks. Supabase's RLS guide puts it plainly: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." Its advice is just as plain: "Enable RLS on every table in an exposed schema."
Crissy Field adds a point that matters for owners. Lovable apps follow recurring patterns, so "an approach that works against one app may then work against others with little extra effort." A mistake that would be obscure in a hand-built app becomes easy to find at scale.
And it's not really about AI. Access control mistakes happen in code written by people too. The difference is that a builder can get you to a working app before anyone on the team has asked who should be able to see each table.
Decision guide
What the page shows vs. what the database will answer
| Consideration | With rules on every table | With rules missing or too loose |
|---|---|---|
| Public key in the page | Fine. It's meant to be public. | Becomes the way in to every table. |
| Signed-out visitor | Sees only what's meant to be public. | Can read more than the page shows. |
| Account B | Sees only B's own records. | Can see A's records too. |
| Uploaded files | Open only to their owner. | Readable by anyone with the link. |
A scanner can tell you that a rule exists. It can't know that account B shouldn't see account A's invoices.
The stranger test you can run this afternoon
You don't need to be an engineer for the first pass. You need a private browser window, two test accounts and a list.
Write down every table and what's in it. Customers, orders, messages, uploads, waitlist. Next to each, write who should see it: everyone, only the person it belongs to, or only your staff. This list is the thing most teams don't have, and it's the thing a developer will ask you for first.
Open your live app as a stranger. Use a private window, don't log in, and click around. Anything personal that appears without logging in is a problem, even if it's buried.
Log in as two different people. Create account A and account B. Add a record as A. Then, as B, try to find it through search, links or the URL. B should never see A's things.
Check your files, not just your tables. IDs, contracts and invoices belong in private storage that only the right person can open.
Look at what you actually collect. If your waiting list only needs an email, stop asking for a birthday or a passport number. Data you don't hold can't leak.
Repeat it after every big change. A new table or feature can quietly reopen access. Crissy Field recommends repeating the review after significant changes, and we agree.
If any step turns up something, don't keep testing on your own. Fix it or get help.
How the work moves
The stranger test, in order
- List your tables
What's in each, and who should see it.
- Visit signed out
Private window, no login.
- Swap accounts
Account B must not see account A.
- Check files
IDs and contracts in private storage.
- Fix and retest
Then repeat after every big change.
What the built-in scans can and can't tell you
Lovable does have security tools. Its security documentation describes a Quick scan that "runs automatically every time you publish" and a Deep scan you can run on demand, and both check database access rules among other things. Supabase has a Security Advisor too. Run both and fix every critical finding.
Just don't treat a clean scan as the end of it. Lovable's own docs say the scans "cannot guarantee complete security" and suggest a professional review for apps handling sensitive data. Crissy Field goes further: "Automated checks are no substitute for a professional security assessment."
The reason is simple. A scanner can tell you that a rule exists. It can't know that account B shouldn't see account A's invoices, because only you know how your business works. That's why the table list from the last section matters more than any tool.
One housekeeping note while you're in there: Supabase says it is deprecating the old anon and service_role keys by the end of 2026, in favor of publishable and secret keys. If you're touching keys anyway, plan that switch now.
If you find something open
Turn on RLS for the affected tables and add a rule for each kind of access. Then run the stranger test again to confirm it's closed.
If a secret key, sometimes called the service-role key, ever ended up in your front-end code, a prompt or a public repository, rotate it. That key skips every rule you just wrote.
Look through your database logs for reads you can't explain. Then talk to a lawyer about whether you have to tell your users or a regulator. That depends on what was exposed and where your customers live, and it's not something to guess at.
And please don't poke at other people's apps to see if they're affected. If you spot a problem in someone else's product, use their published security contact.
When the app has outgrown the builder
Lovable is good at getting an idea in front of people fast, and plenty of apps should stay simple. The moment it holds payments, identity documents, health details or anything a customer trusted you with, it needs someone who owns the permissions, not just the screens.
We wrote about when an AI builder is enough and when you need an engineering partner. This research is a clear example of where that line sits.
If your app has real customer data in it and you're not sure who can read what, our web applications team can review the access rules, fix what's open and set it up so the next feature doesn't undo the work. Talk to us.
Related work: Sutton Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.