We scanned 50 vibe-coded apps with Sekrd. 3 got BLOCK, all had findings.

Vibe coding is the fastest way to build an app in 2026. But how secure are those apps?

We ran 50 real Sekrd scans across Lovable, Replit, Bolt.new, v0 (Vercel), and Cursor-built apps. Every scan ran all 10 security providers: secrets detection (55 patterns), security headers, DAST probes, auth flow analysis, dependency CVEs, and more. We also manually inspected 30 apps for exposed Supabase credentials in client-side JavaScript.

The results: every single app had security findings. Three Replit apps got BLOCK verdicts with critical vulnerabilities, including one that leaked Anthropic, OpenAI, and Google API keys in client-side code. And 37% of Lovable apps expose their Supabase database credentials in the browser.

Other researchers found the same thing

We are not the first to look at this. Multiple independent research teams reached the same conclusion:

• Escape.tech audited 5,600 vibe-coded apps and found 2,000+ vulnerabilities, 400 exposed secrets, and 175 instances of PII leakage
• Tenzai built 15 identical apps across Claude Code, Codex, Cursor, Replit, and Devin, producing 69 vulnerabilities (6 critical)
• A study of 1,645 Lovable apps found that over 10% had critical RLS flaws
• In February 2026, Moltbook, a social platform built entirely through vibe coding, suffered a real data breach

This is not a theoretical risk. This is happening right now, at scale.

Our methodology

We selected 30 publicly deployed apps from the Made With Lovable gallery, web search results, and community showcases. For each app we:

1. Downloaded the HTML and all linked JavaScript bundles
2. Searched for Supabase project URLs (*.supabase.co) and anonymous JWT keys
3. Searched for Firebase API keys, Stripe live keys, and OpenAI keys
4. For apps with exposed Supabase credentials, tested read access on 30 common table names using only the publicly exposed anon key

We did not attempt to write, update, or delete any data. All testing used only information already exposed in the client-side code.

Sekrd scan results

All 50 apps were scanned through Sekrd on April 13, 2026. Each scan ran 10 security providers in parallel.

100% of apps had at least one security finding. Average: 9.7 findings per app. All findings include AI-ready fix prompts for Cursor, Lovable, and Claude Code.

Platform comparison

Here is what a typical scan looks like for each platform:

Lovable — 86/100 SHIP (best average score)

Bolt.new — 84/100 SHIP

v0 (Vercel) — 74/100 SHIP (worst v0 score in our sample)

The 3 apps that got BLOCK

All three BLOCK verdicts were Replit apps. Replit scored worst across all platforms (avg 68/100).

BLOCK #1 (score 50) — 3 AI API keys leaked in client code:

Anthropic, OpenAI, and Google API keys found in client-side JavaScript. Anyone who opens DevTools can extract these keys and run up charges. This is the same vulnerability class that cost one developer $12,000 in 8 hours.

BLOCK #2 (score 50) — Discord bot token leaked:

Discord bot token in client-side JavaScript plus three unprotected API endpoints. The token allows an attacker to control the bot, read messages, and impersonate it.

BLOCK #3 (score 50) — Client data exposed: Unprotected /api/settings/clients and /api/clients endpoints. Client data accessible without authentication.

All three apps are live right now. URLs redacted.

Credential exposure (manual check)

In addition to Sekrd scans, we manually inspected 30 apps' JavaScript bundles for exposed database credentials:

Finding 1: 37% of Lovable apps expose Supabase credentials

7 out of 19 Lovable apps (37%) had their Supabase project URL exposed in client-side JavaScript. Of those 7, 6 also exposed the anonymous JWT key.

This happens because Lovable generates Vite + React apps. Environment variables prefixed with VITE_ get bundled into the client-side build. When Lovable sets up Supabase, it stores credentials as VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY, making them visible to anyone who opens DevTools.

To be clear: the Supabase anon key is designed to be public. The protection is supposed to come from Row Level Security (RLS) policies. But when those policies say USING(true), the anon key becomes a master key to the entire database.

Finding 2: One app had real user data publicly readable

Of the 6 Lovable apps with exposed anon keys, we tested read access against 30 common table names (profiles, users, registrations, etc.):

• 1 app had a registrations table with real data publicly readable — anyone with the anon key (visible in the page source) could read the full table
• 2 apps had tables that were accessible but empty (RLS was not blocking anonymous reads, there was just no data yet)
• 2 apps had Supabase projects paused (free tier inactivity) — API returned errors
• 1 app had Supabase URL but the anon key was not in the scanned JS chunks

The app with exposed registrations data is a real event management site (URL redacted). The data was accessible to anyone with a browser. No authentication. No special tools. Just a curl command with the publicly visible key.

Finding 3: Replit apps use a different stack

None of the 6 Replit apps we scanned used Supabase. Replit apps tend to use server-rendered backends (Flask, Express, PHP) where database credentials stay on the server. This architectural difference means Replit apps are less likely to expose database credentials in client-side code, though they may have other vulnerabilities.

Why this happens

The root cause is the same across all platforms: AI optimizes for functionality, not security. When you prompt "add a database table for user profiles," the AI generates code that works immediately. That means permissive RLS policies, client-side API calls, and environment variables in the browser bundle.

The most common dangerous pattern we see in Lovable-generated code:

CREATE POLICY "Allow all access" ON profiles
  FOR ALL USING (true) WITH CHECK (true);

The AI enables RLS (good) but then creates a policy that allows everything (catastrophic). The developer sees "RLS: Enabled" in the Supabase dashboard and assumes they are protected. They are not.

How to fix it in 30 seconds

Every USING(true) policy should be replaced with a policy scoped to the authenticated user:

-- Drop the dangerous policy
DROP POLICY "Allow all access" ON profiles;

-- Create proper read policy
CREATE POLICY "Users can read own profile" ON profiles
  FOR SELECT USING (auth.uid() = user_id);

-- Create proper write policy
CREATE POLICY "Users can update own profile" ON profiles
  FOR UPDATE USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

How to check if your app is vulnerable

Manual check: Open your browser DevTools (F12), go to Sources, and search for supabase.co. If you find your project URL and a JWT token starting with eyJ, your credentials are exposed. Then check your RLS policies in the Supabase SQL Editor:

SELECT schemaname, tablename, policyname, permissive, cmd, qual
FROM pg_policies WHERE schemaname = 'public';

If you see qual = true, that table is exposed.

Automated check: Run a free Sekrd scan on your URL. We check 10 security categories: exposed secrets (55 patterns), Supabase RLS policy logic, Firebase rules, auth flows, payment webhook verification, dependency CVEs, security headers, DAST probes, cost exposure analysis, and MCP server security. You get a SHIP or BLOCK verdict in under 3 minutes, plus copy-paste fix prompts for Cursor, Lovable, or Claude Code.

Raw data

Full scan results for all 30 apps (URLs redacted, Supabase project refs shown):

Scan conducted April 13, 2026. Apps selected from public galleries and web search results. All testing used only publicly exposed credentials. No data was modified.

What the industry should do

1. Default to deny-all RLS policies and require developers to explicitly grant access
2. Warn when deploying with permissive policies, the same way browsers warn about mixed content
3. Include security scanning in the deploy pipeline, not as an afterthought
4. Generate auth-scoped policies by default when creating tables with user data

Until then, the responsibility falls on builders. Scan before you ship.