We ran an open-source audit over 190 public apps built with Lovable and Emergent. Of the 83 Lovable apps whose database rules we could read in full, 20 (24%) let anyone change or delete data without signing in. Across all 190 apps, 40 (21%) had a secret that looked real either committed to the repository or shipped to the browser.
If you saw the Reddit post about scanning 183 public Lovable apps, this is a different study. We state our method below. We replay every migration in order to get each app's final database rules. We count policies that let anyone change or delete data, not only tables where row-level security is off. We cover Emergent as well as Lovable. And we measure what breaks when you leave the platform.
Why we looked
AI app builders have made shipping easy. What comes after is harder: is the app you shipped safe to keep running, and what would it take to own it? The platform keeps the database, the sign-in and the deployment out of sight, and that is where most of the risk sits. We wrote offramp, an MIT-licensed tool that answers both questions from the repository alone. Before releasing it, we ran it on public apps to see what it would find, and how often it would be wrong.
How we did it
We found apps by the files each platform generates. For Lovable, that is the lovable-tagger package and src/integrations/supabase/client.ts. For Emergent, it is the emergentintegrations package, a test_result.md file and a backend/ + frontend/ layout. We excluded forks, archived repositories and templates, kept one repository per owner, and drew a random sample of repositories active in 2025 or 2026: 125 from Lovable and 65 from Emergent.
The audit only reads files. It sent no request to any running app and used no credentials. We checked a sample of each kind of finding by hand, fixed every false positive we found, and ran it again before counting. The results below are aggregates. We do not name any repository or publish per-app results.
Finding 1: the database is the only lock, and it is often open
In a typical Lovable app, the browser talks straight to Supabase using a public key. That is by design. The key is meant to be public, and row-level security (RLS) is what stops one visitor from reading or rewriting another's data. CVE-2025-48757 was about this exact layer.
105 of the 125 Lovable apps use Supabase. For 83 of them, we could replay every migration and know the final rules. We counted the other 22 as unknown, not as safe. Their tables were created in the dashboard, they use dynamic SQL, or their migrations are not valid SQL. Six use CREATE POLICY IF NOT EXISTS, which PostgreSQL does not support.
Of those 83 apps, 4 have tables where row-level security is never turned on. 18 have an update, delete or all-operations policy that applies to anyone and whose condition is simply true. Together, 20 apps (24%) let anyone change or delete data without signing in. 44 (53%) let anyone read whole tables. That is sometimes intended, as with a product catalogue, and sometimes not. 33 let anyone add rows, which is usually a contact form and usually fine.
Finding 2: secrets in the wrong place
15 of the 65 Emergent apps (23%) commit a credential that looks real, most often a third-party API key or the JWT signing secret in backend/.env. Anyone who can read the repository can use it. With a signing secret, that means creating valid sessions for any user. Deleting the file later does not help: the value stays in the git history.
15 of the 125 Lovable apps (12%) read a variable with a secret-sounding name, such as VITE_OPENAI_API_KEY, in browser code. Vite compiles these variables into the JavaScript bundle, so every visitor can read the value. In 5 apps it was a Supabase service_role key, which bypasses every row-level security policy.
Finding 3: what breaks when you leave
Leaving is the part nobody plans for. 40 of the 65 Emergent apps (62%) have at least one thing that stops working off the platform. 14 (22%) sign users in through Emergent's own auth service, so after a move nobody can log in until sign-in is replaced. 27 have their Emergent preview URL written into the app, often as the backend address the frontend was built against.
On Lovable, 29 of the 125 apps (23%) have a coupling like this. 22 (18%) send their AI calls through Lovable's AI gateway, which is billed through the platform and does not work anywhere else.
What we could not see
A repository is not the running app. Policies changed in the Supabase dashboard never reach the migrations, so some apps flagged here may have fixed the problem there. Others may have open tables that hold nothing sensitive. Public repositories may also differ from private ones. Treat these numbers as a measure of how often the problem is written into the code, not as a count of breached apps.
Check your own app
offramp is free and runs on your machine. It reads only files, sends nothing anywhere, and tells you what it could not check. To run it: git clone https://github.com/devopsgenie-ai/offramp then python3 offramp/skills/offramp/scripts/audit.py path/to/your-app --out report. See the README for what each check means.
If it flags something, the fixes are mostly short. Turn on row-level security for every table in public. Replace true with a condition on the row's owner. Move secret keys out of the frontend and into server-side functions. Rotate anything that was ever committed.
offramp is maintained by DevOps Genie. If you would rather have someone fix what it finds, or set up infrastructure you own, talk to us.