We read 512 Lovable app migrations: 16% let visitors rewrite data
An analysis of migration files from 512 public Lovable apps on GitHub reveals 16.2% misconfigured RLS, allowing signed-out users to modify tables.
Stock photo for illustration only, not from the actual event
- Analyzed migration files from 512 public apps built with Lovable on GitHub
- Found 16.2% of projects allow signed-out visitors to update or delete table rows
- Discovered 10.4% of tables were created without enabling Row Level Security (RLS)
- VibeRaven open-source tool was used to scan the code before database deployment
Building applications with AI coding assistants has become remarkably fast and accessible, but it also introduces hidden security pitfalls. A recent security review examined the migration files of 512 public projects built using the Lovable platform and backed by Supabase databases, revealing alarming configuration oversights.
Ohad Kr, creator of VibeRaven—an open-source repository checker for Vercel and Supabase applications—analyzed the codebase shipped by these apps rather than querying live databases. The scan focused on the migration files included in public Lovable repositories discovered via GitHub code search in October 2026.
Out of 512 public projects examined, 83 repositories (16.2%) shipped a migration policy that permitted signed-out visitors to update or delete every single row in a table. Furthermore, 7 projects (1.4%) allowed any signed-in user to do the same, while 53 projects (10.4%) created tables without ever enabling Row Level Security (RLS) on them.
Stock photo for illustration only, not from the actual event
A key root cause previously highlighted by UpGuard regarding exposed Supabase databases is that tables created programmatically through APIs—which is how coding agents operate—do not enable RLS by default. Scanning the migration step before database deployment helps uncover these vulnerabilities early in the development lifecycle.
"Policy "Owners can update their agents" on public.agents lets anyone, signed in or not, update every row, to any values: using (true). The name says "Owners can update their agents", but nothing in the policy checks who the caller is."
VibeRaven Scan Report
Another recurring pattern involved policies granting the service role full management access with using (true). Because the service role already bypasses RLS entirely, adding such a policy unnecessarily exposes the table to everyone else unless explicitly restricted to the service role.
From a security perspective, Row Level Security (RLS) in Supabase is critical for enforcing data protection at the individual row level. When developers rely on AI or automated coding tools without carefully verifying migration files, permissive SQL snippets like using (true) on update or delete commands can easily create severe vulnerabilities where unauthorized users manipulate critical data, regardless of how secure the policy name sounds.
However, these numbers do not mean that 16.2% of all live Lovable apps are currently compromised. The sample is drawn from public GitHub repositories, which heavily lean toward side projects, and the committed code may differ from what is currently deployed in production environments where fixes might have been applied via the dashboard.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment