What actually happened
Over the past week, several people ran large scans across apps built with Lovable and published what they found. The pattern was the same each time. A lot of these apps hand back customer data, names, emails, orders, and messages, to a plain anonymous request, with no account and no hacking involved.
Your builder tells you the app is live. It never tells you that the same database is quietly answering strangers. That gap is the whole story, and it is why this slipped past so many launches that looked finished.
The receipts are at the bottom of this page. The short version is that this is a real, common mistake, not a one-off, and it is also one of the most fixable ones.
Why Lovable and Supabase apps leak
Supabase ships an anonymous key that is meant to live in your front end. It is public by design. The safety does not come from hiding that key. It comes from Row Level Security, a rule on each table that decides which rows an anonymous request is allowed to read.
AI builders scaffold tables fast, and Row Level Security is easy to leave off or leave too open. When that happens, the public key becomes a door into a table that should have been locked, and nothing in the running app looks wrong. The public key is not the mistake. The unprotected table is.
Is your app affected? Check it free
Smoke Run runs a free self-check for exactly this. You enter your own app address, and it reads your public page and asks your project which tables answer a request with no login. It reports the result in plain words.
The check is read-only and polite by design. It never reads the contents of any row, it never uses any key it finds, and it stores nothing. Only run it on apps you own. It is an outside check for one common, high-impact mistake, not a full audit, so treat a clean result as one real risk cleared rather than a guarantee.
If you are exposed, here is the fix
Do not panic and do not start deleting things. The fix lives in Supabase. Turn on Row Level Security for the open table, then add a policy that matches who should actually be allowed to read it, which for most app data is only the signed-in owner of the row.
Then run the check again to confirm the table no longer answers an anonymous request. Open data is one of several silent failures. A checkout that breaks without an error is another, and Smoke Run watches that money path too.