Lovable Security: CVE-2025-48757, RLS Failures, and VibeScamming Risks

What is Lovable?

Lovable (formerly GPT Engineer) is an AI tool that lets you build full-stack web apps by chatting with AI. Describe what you want, and Lovable generates a complete React + TypeScript application with a Supabase backend. One-click deployment gets your app live on a *.lovable.app subdomain.

The appeal is obvious for vibe coders: go from idea to deployed app in minutes without writing code. Lovable hit a $1.8B valuation in February 2025, making it one of the most valuable AI coding startups. The tech stack is modern: React, TypeScript, Tailwind CSS, Vite, Shadcn UI, and Supabase for database, auth, and storage.

The problem? Lovable's speed-first approach means security often comes second. When you don't see the database configuration, you don't think about it - and that's exactly where things go wrong.

The CVE-2025-48757 Disaster

In March 2025, security researcher Matt Palmer discovered a critical vulnerability in Lovable-generated apps. The root cause: Row Level Security (RLS) was either not enabled or implemented incorrectly on Supabase tables.

What Went Wrong

When you create a table in Supabase, RLS is disabled by default. Without RLS policies, anyone with the Supabase anon_key (which is always public in the frontend) can query the database directly. Lovable-generated apps often shipped without proper RLS configuration, exposing all user data.

1. Attacker finds Lovable-built app (*.lovable.app)
2. Views page source → finds Supabase URL and anon_key
3. Connects to Supabase directly with the anon_key
4. Missing RLS = full read/write access to ALL data

The Scale of Exposure

Researchers scanned 1,645 projects from Lovable's "Lovable Launched" showcase and found:

• 303 vulnerable endpoints across 170 projects
• 10.3% of analyzed applications had inadequate security
• Exposed data included: emails, phone numbers, home addresses, personal debt amounts, API keys (Google Maps, Gemini, eBay), Stripe credentials, financial transactions

Disclosure Timeline

VibeScamming: The Phishing Risk

Beyond database security, Lovable has another problem: it's highly susceptible to generating phishing content. Guardio Labs tested AI tools' resistance to malicious prompts and developed a "VibeScamming Benchmark."

Benchmark Results

What Attackers Can Build

• Pixel-perfect phishing pages: Login pages mimicking Microsoft, Google, banks
• Auto-deployment: Instantly hosted on trusted *.lovable.app subdomains
• Credential harvesting: Forms that capture and exfiltrate login data
• Admin dashboards: Real-time monitoring of stolen credentials
• Data exfiltration: Send data to Firebase, Telegram, or external servers

The risk for legitimate vibe coders? Your app shares infrastructure with potential phishing pages. And if you're building auth flows, Lovable might generate patterns similar to what attackers use - meaning your legitimate login page could look suspicious to security tools.

Common Security Issues in Lovable Apps

Issue 1: Missing RLS Policies

The most critical issue. When RLS is disabled, anyone can query your database.

-- Table created without RLS
CREATE TABLE users (
  id UUID PRIMARY KEY,
  email TEXT,
  created_at TIMESTAMPTZ
);
-- RLS not enabled = anyone can read ALL users

-- Enable RLS and create proper policy
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users can only access own data"
ON users
FOR ALL
USING (auth.uid() = id);

Issue 2: Overly Permissive RLS

Having RLS enabled isn't enough - the policy must actually restrict access. This is a classic IDOR vulnerability.

-- Policy allows too much access
CREATE POLICY "Allow all authenticated"
ON sensitive_data
FOR SELECT
USING (auth.role() = 'authenticated');
-- ANY logged-in user sees ALL data - not just their own

Issue 3: Exposed API Keys

Lovable apps expose Supabase credentials in frontend code. The anon_key is designed to be public, but real API keys (Google Maps, Stripe, etc.) should never be in client code. This relates to hardcoded secrets vulnerabilities.

// Lovable exposes these (by design - this is expected)
const supabase = createClient(
  'https://xxx.supabase.co',
  'eyJhbG...' // anon key - ALWAYS public
)

// Security depends ENTIRELY on RLS policies
// If RLS is missing or weak, this key = full access

Issue 4: Client-Side Validation Only

Lovable often generates validation only in the frontend, which attackers bypass by calling the API directly.

// Client-side validation only - easily bypassed
const handleSubmit = (data) => {
  if (data.amount > 0) {  // Attacker skips this check
    await supabase.from('transactions').insert(data)
  }
}

How to Secure Your Lovable App

Step 1: Audit Every Table

Go to your Supabase dashboard and check RLS status for all tables:

-- List all tables and their RLS status
SELECT
  schemaname,
  tablename,
  rowsecurity as "RLS Enabled"
FROM pg_tables
WHERE schemaname = 'public';

Step 2: Enable RLS on ALL Tables

-- Enable RLS on each table
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
ALTER TABLE transactions ENABLE ROW LEVEL SECURITY;
-- Repeat for EVERY table with user data

Step 3: Create Proper Policies

-- Users can only see their own data
CREATE POLICY "user_isolation" ON your_table
FOR ALL USING (auth.uid() = user_id);

-- Public read, authenticated write
CREATE POLICY "public_read" ON posts
FOR SELECT USING (true);

CREATE POLICY "auth_write" ON posts
FOR INSERT WITH CHECK (auth.uid() = author_id);

-- Admin-only access
CREATE POLICY "admin_only" ON admin_data
FOR ALL USING (
  auth.uid() IN (SELECT id FROM users WHERE role = 'admin')
);

Step 4: Protect Real API Keys

• Never hardcode API keys (Google Maps, Stripe, etc.) in frontend
• Use Lovable's Secrets feature for sensitive values
• Move sensitive operations to Supabase Edge Functions

Step 5: Request Security Review

In Lovable, you can prompt: "review my app's security". The AI will scan for common issues. But remember: this scanner has limitations. Manual review is still required.

Lovable vs Other AI Tools

The key difference: Lovable deploys full-stack apps with databases. Other tools like Cursor and Bolt generate code that you deploy yourself, so you're forced to think about database configuration. Lovable's convenience hides this complexity - and the security decisions it makes for you are often wrong.

For Supabase-specific security, see our guides on Next.js + Supabase security and SvelteKit + Supabase security.

AI Fix Prompt: Audit Your Lovable App

Copy this prompt into Lovable or any AI assistant to audit your app:

Frequently Asked Questions

Related Articles