Is vibe coding secure?

The tools can produce secure apps, but the defaults often aren't. The 2026 exposures mostly came from apps left public by default, databases without row-level security, secret keys shipped to the browser, and access checks that confirm a user is logged in without checking what they own. None of these show up while you build, because a prototype never sees a stranger.

How many vibe-coded apps leak data?

In a scan reported in May 2026, RedAccess examined about 380,000 publicly accessible assets on Lovable, Base44, Replit and Netlify and found about 5,000, or 1.3%, exposing sensitive corporate or personal data, verified independently by Axios and Wired. In October 2025, Escape scanned 5,600 vibe-coded apps and found more than 2,000 high-impact vulnerabilities and over 400 exposed secrets.

What is Supabase row level security and why does it matter?

Row level security (RLS) is a Postgres feature Supabase uses to decide, row by row, which records a user may read or change. Many vibe-coded apps call the database directly from the browser with a public key, so RLS is the only thing stopping any visitor from reading every row. CVE-2025-48757 documented missing or insufficient RLS in Lovable-generated Supabase projects across more than 170 production apps.

How do I secure a vibe-coded app?

Make the app and its database private unless they must be public, turn on row level security on every table with policies per user, move every secret key out of the frontend, check ownership on every request rather than just login, and review who can reach the app. Then have someone who did not build it try to read another user's data.

Vibe Coding Security: The Risks and a Checklist (2026)

Q: What happened with Lovable's security in 2026?

A researcher reported on 3 March 2026 that Lovable's project API checked for a valid login but not whether the user owned the project, a broken object level authorization flaw. Through a free account it exposed other users' source code, hardcoded Supabase credentials and service keys, AI chat histories and personal data. It went public on 20 April after 48 days without a fix. Lovable said it was not a breach and pointed to public project settings and unclear documentation.

A quickly built app with a key left on top and database rows spilling out of an open side, while a mechanical arm fits a lock onto each row

Vibe coding security comes down to five mistakes, and almost every exposure this year was one of them: apps public by default, databases without row-level security, secret keys shipped to the browser, access checks that confirm a login but not ownership, and nobody reviewing what was exposed. The scale is not hypothetical. In May 2026, RedAccess found about 5,000 apps built on Lovable, Base44, Replit and Netlify leaking sensitive data, from a bank's internal financials to patient conversations. In April, a Lovable flaw exposed other users' source code and database credentials through a free account. None of it needed a clever attacker. It needed a stranger to look. Building with these tools is often the right call, and we say so in what a vibe-coded app really costs. This post is about the step after: what to check before an AI-built app touches customer or employee data.

What happened this year

RedAccess, May 2026. Researching shadow AI, RedAccess scanned about 380,000 publicly accessible apps and databases on Lovable, Base44, Replit and Netlify. About 5,000 (1.3%) exposed sensitive corporate or personal information. Axios and Wired verified examples: a shipping company's vessel schedules, a health company's list of active UK clinical trials, a Brazilian bank's internal financials, patient conversations at a children's care facility (VentureBeat). Several platforms make apps public unless the builder switches them to private, and many get indexed by search engines.

Lovable, March–April 2026. Lovable's project API checked for a valid login but not whether the user owned the project: a broken object level authorization flaw. Five API calls from a free account were reportedly enough to read other users' source code, hardcoded Supabase credentials and service keys, AI chat histories, and personal data. Reported on 3 March, public on 20 April after 48 days without a fix. Lovable said it was not a breach, and later acknowledged that early free-tier users could not make projects private (State of Surveillance).

The older pattern. CVE-2025-48757 documented missing or insufficient row-level security in Lovable-generated Supabase projects across more than 170 production apps. Escape's October 2025 scan of 5,600 vibe-coded apps found more than 2,000 high-impact vulnerabilities and over 400 exposed secrets.

The five mistakes

1. Public by default. The app, its preview URL or its database is reachable by anyone, sometimes indexed by Google. Fine for a demo. Not fine once real data goes in.

2. No row-level security. Many of these apps talk to the database straight from the browser with a public key. If the tables have no row-level security policies, that public key reads everything. Every user, every row.

3. Secrets in the frontend. A service key, payment key or API key bundled into the JavaScript ships to every visitor. Open the browser's developer tools and it is there.

4. Logged in is not allowed. The Lovable flaw in miniature: the code checks that a request comes from a user, not that it is this user's record. Change an ID in the URL and you see someone else's data.

5. Nobody looked. The person who built it tested it as themselves. Nobody tried to be someone else.

A checklist before you ship

Run these before an AI-built app holds customer or employee data. Most take minutes.

Visibility. Is the project private? Is the preview URL private? Search the app's domain on Google to see what is indexed.
Row-level security. In Supabase, is RLS enabled on every table, with policies that restrict rows to their owner? A table with RLS on and no policy is locked. A table with RLS off is open.
Keys. Search the built JavaScript for service_role, sk_live, secret and your provider's key prefixes. Only public, restricted keys belong in the browser.
Ownership checks. Log in as user A, copy a URL or API call for A's record, log in as user B, and replay it. If B sees A's data, stop.
Who can sign up. If it's an internal tool, require your company sign-in (Google or Microsoft) and block everyone else.
Inputs and exports. Can anyone call the "export all" endpoint? Is there a rate limit on it?
A second pair of eyes. Someone who didn't build it should try steps 3 and 4.

What we find in audits

When we audit an AI-built app before it goes company-wide, the security list above comes up alongside the same engineering gaps every time: N+1 queries that collapse under real data, logic pasted in four places, no tests, no database migrations, and secrets in the repository. None of it means throwing the app away. It means a short list of fixes in the right order, and someone responsible for them after launch. An AI reviewer on every pull request helps from then on, but it reads one change at a time, which is why Claude Code Review and a code audit answer different questions.

Also: .NET 8 end of life: what to do with your apps.

Vibe Coding Security: What 5,000 Leaking Apps Have in Common, and a Checklist Before You Ship

This year a scan found about 5,000 apps built on Lovable, Base44, Replit and Netlify leaking corporate or personal data, and Lovable had a flaw that exposed other users' code and database keys. Almost none of it needed a clever attacker. Here are the five mistakes, and how to check yours.