Is Vibe Coding Safe? What the Lovable and Moltbook Breaches Teach

Vibe coding is not safe to ship to real users by default. The two biggest 2026 breaches, Moltbook and Lovable, leaked private user data for the same two reasons: database security (called Row Level Security) was turned off, and secret keys were sitting in code that anyone could read in their browser. The AI wrote code that worked; it just forgot to lock the doors, and that gap between "it works" and "it is safe" is the whole problem.

---

---

Why this matters to you

If you built an app with an AI tool and you are about to let real people sign up, this is the part nobody warns you about. The app feels finished. It logs people in, it saves their data, it looks professional. But "feels finished" and "is secure" are two different things, and AI coding tools are very good at the first one and very bad at the second.

The fix is not hard. It is three checks you can do in an afternoon. But you have to know to do them, because the AI will not.

The one root cause behind both breaches

Here is the single idea that explains everything below.

Most AI-built apps use a database service called Supabase. Supabase gives your app a public key (the "anon key") that lives in your website's code. This is on purpose. The anon key is safe to expose in your browser code, but only if you have turned on Row Level Security on every table.

Row Level Security (RLS) is a rule that says which rows of data each user is allowed to see. With RLS on and set up right, you can only read your own rows. With RLS off, anyone holding that public key (which is everyone, because it is in your code) can read and overwrite every row in the database.

AI tools generate working Supabase queries all day long. They almost never turn on RLS or write the per-user rules. That is the bug. That is both breaches.

What happened at Moltbook (February 2026)

Moltbook was built over a weekend in January 2026. The founder reportedly wrote zero lines of code. On February 1, security firm Wiz Security ran a quick, non-intrusive review and found the front door wide open.

The anon key was sitting in the JavaScript bundle (the code your browser downloads). RLS was off on every table. A single API call let anyone act as any user. The exposure, as reported by Wiz: about 1.5 million API tokens, 35,000 emails, and 17,000 Twitter handles. Finding it took minutes. To Moltbook's credit, they patched it the same day.

What happened at Lovable (April 2026)

Lovable is an AI vibe-coding platform reported at a $6.6 billion valuation. The flaw here had a name: BOLA, which stands for Broken Object Level Authorization. In plain words, the app checked that you were logged in but never checked whether the thing you asked for actually belonged to you.

A researcher reported on March 3, 2026 that any free Lovable account could pull another user's source code, database credentials, and AI chat history in 5 API calls. It reportedly affected every project created before November 2025. The report sat open on HackerOne for 48 days, and Lovable initially described the access as "intentional behaviour" before the breach went public.

Moltbook vs Lovable: same root cause, different surface

This is the norm, not two unlucky apps

You might think these were two careless teams. The scans say otherwise.

• Escape.tech scanned 5,600 vibe-coded apps and reported 2,000+ high-impact vulnerabilities and 400+ exposed secrets.
• SupaExplorer reported that 11% of more than 20,000 indie launch URLs exposed their Supabase credentials right in the frontend.

So roughly one in nine apps from a sample of indie launches was leaking. These are not edge cases. They are what you get when a tool is rewarded for producing a working demo and never asked what happens once a stranger signs up.

The single most common RLS mistake

When AI tools do add a security rule, they often add the wrong one. Watch the difference, because one word changes everything:

• Wrong: auth.role() = 'authenticated' means "anyone who is logged in can see this row." Every signed-up user can read every other user's data.
• Right: auth.uid() = user_id means "you can only see rows where the user id is yours."

One wrong condition turns your whole database into a public file for anyone with an account. This is the exact category of mistake that a build system with row-level security on by default, plus a clear CLAUDE.md instruction file telling the AI to scope every table to its owner, is designed to prevent.

Three checks any founder can run today

You do not need to code to do these.

1. Open your Supabase dashboard, go to Authentication, then Policies. Confirm every table has RLS enabled, shown by a green shield. Any table without it is readable by the public.
2. Open your live site, view the page source or the JavaScript files, and search for the text service_role. That is the admin key and it must never reach the browser. If it shows up, rotate (replace) the key immediately in Supabase.
3. Run a free passive scan with Escape.tech or SupaExplorer before you accept your first real user. They check from the outside, the same way an attacker would.

If all three pass, you have closed the doors that sank Moltbook and Lovable.

The structural fix

Vibe coding platforms optimize for speed of generation. They are graded on how fast they turn a sentence into a running app, not on what happens after you hand that app a real person's data. That is why the security gap keeps showing up.

The structural answer is to make the safe thing the default. A production build system enforces RLS on every table, keeps the admin service_role key on the server where browsers cannot see it, and runs a security check before a feature is marked done. That is the idea behind the Build This Now Code Kit, a $29 one-time harness for Claude Code that ships a SaaS skeleton with auth, Stripe payments, and row-level security already wired in. Related building blocks worth knowing: Claude Code subagents for review, MCP servers for connecting tools, and a CLAUDE.md file that holds your security rules so the AI follows them every time.

FAQ

Is vibe coding safe for real users?

No, not by default. Both major 2026 vibe-coding breaches, Moltbook and Lovable, exposed user data because the AI generated working code without enabling database security. Before you accept real users, audit for Row Level Security and exposed API keys.

What happened in the Lovable data breach?

A researcher reported in March 2026 that any free Lovable account could access another user's source code, database credentials, and AI chat history using 5 API calls. Lovable left the report open for 48 days and initially called the access "intentional behaviour." It reportedly affected every project created before November 2025.

What is Row Level Security and why does it matter for AI-built apps?

Row Level Security (RLS) is a Supabase and PostgreSQL feature that limits which database rows each user can read or write. Without it, anyone holding your database's public key (which is visible in your JavaScript) can read or overwrite every row. AI tools generate working queries but rarely turn RLS on by default.

How do I check if my vibe-coded app is secure?

Three quick checks. Open your Supabase dashboard and confirm RLS is enabled on every table (green shield). Search your deployed JavaScript for the text service_role and rotate the key right away if it appears. Run a free passive scan at Escape.tech or SupaExplorer before you accept real user data.