Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 4 min read

Lovable Data Leak 2026: 24,664 AI Apps Exposed 80,000+ User Records via Supabase

The $0 Security Breach: How 24,664 AI-Built Apps Leaked Your Passport Number A Cloud Security Analysis of the Lovable/Supabase Data Exposure The Hook In November 2026, security researchers scanned 159,041 AI-genera

The $0 Security Breach: How 24,664 AI-Built Apps Leaked Your Passport Number

A Cloud Security Analysis of the Lovable/Supabase Data Exposure

The Hook

In November 2026, security researchers scanned 159,041 AI-generated web applications.

They didn't hack anything.

They didn't use zero-days.

They simply knocked on doors that were left wide openβ€”and found 80,000+ user profiles, unencrypted passport numbers, payment details, and 200,000 private chat messages sitting in plain sight.

The culprit? A "no-code" promise that made building easy and securing optional.

This is the story of how AI democratized software creationβ€”and accidentally democratized data breaches.

The Setup: When "Easy" Becomes "Exposed"

Lovable is a Swedish AI startup that turns plain English into working web applications. Type "build me a customer portal," and it appears. No code. No technical knowledge required.

The marketing is seductive. The terms and conditions? Less soβ€”they quietly place all security responsibility on the user.

Here's the gap: Non-technical founders built production apps with sensitive data. They didn't know they needed to secure the backend. And nobody forced them to learn.

The result was predictable.

The Technical Autopsy: What Actually Happened

Researchers focused on Supabaseβ€”the open-source Firebase alternative that Lovable integrates for database functionality. Of the 159,041 projects analyzed:

Β· 34,545 used Supabase
Β· 24,664 leaked database records immediately upon page load
Β· 7,403 exposed email addresses across 10,560 tables

The Root Cause: Row Level Security (RLS) Turned Off

Supabase uses a client-side JavaScript library. Your frontend holds a public anon keyβ€”by design. That key is meant to be public.

But here's the catch: That public key can only access what your database policies allow.

When RLS is disabled or misconfigured:

Β· Anyone with browser DevTools can see your anon key
Β· Anyone with that key can query your database
Β· Anyone can read every row in every table

The researchers didn't brute-force passwords. They opened Chrome, inspected network traffic, grabbed the key, and queried tables like profiles, messages, and payments.

One request. Full access.

The DevSecOps Nightmare: AI Code Uniformity

Here's where it gets worse.

AI generates code using recurring architectural patterns. Lovable apps follow predictable structures:

Β· Same Supabase initialization
Β· Same client-side key exposure
Β· Same missing RLS configurations

This uniformity is a gift to attackers.

A single automated script that detects "Supabase + Lovable" can scan thousands of applications simultaneously. What worked against one app works against all of them.

The scale of exploitation is now a function of AI's consistency, not attacker sophistication.

The Damage Report

The exposed data wasn't abstract. It included:

Data Type Example
Identity Documents 1,000+ records with passport numbers, expiration dates, nationalities
User Profiles 80,000+ full names, emails, birthdates, gender
Private Communications 200,000+ chat messages, internal WhatsApp threads
Financial Records Invoices, payment details, ticket codes
Business Intelligence AI-generated email summaries about tenants, owners, partners

One provider leaked 280,000 customer emails.

This is phishing fuel. Identity theft raw material. Fraud starter kit.

The Fix: Row Level Security in Supabase

If you're building on Supabaseβ€”with or without AIβ€”here's the non-negotiable first step:

Step 1: Enable RLS on Every Table

ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE messages ENABLE ROW LEVEL SECURITY;
ALTER TABLE payments ENABLE ROW LEVEL SECURITY;

Do this before you add data. Not after.

Step 2: Write Explicit Access Policies

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

-- Users can only read their own messages
CREATE POLICY "Users read own messages"
ON messages
FOR SELECT
USING (auth.uid() = sender_id);

Step 3: Test Like an Attacker

  1. Open your app in an incognito window
  2. Open DevTools β†’ Network tab
  3. Find your Supabase API calls
  4. Copy the anon key
  5. Use curl to query a table you shouldn't access
curl 'https://your-project.supabase.co/rest/v1/profiles?select=*' \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

If you see data you shouldn't, you're exposed.

The DevSecOps Checklist for AI-Built Apps

Before any AI-generated app touches real data:

Check Why It Matters
βœ… RLS enabled on all tables Blocks unauthorized row access
βœ… Explicit SELECT, INSERT, UPDATE, DELETE policies RLS alone isn't enough
βœ… anon key limited to intended public data Never allow it to bypass RLS
βœ… API response payloads inspected See what the frontend actually receives
βœ… Automated fuzzing of database endpoints Catch what manual review misses
βœ… IAM/RBAC validated before production Defense in depth

The Lesson: AI Doesn't Remove Responsibility. It Redistributes It.

Lovable's marketing promises ease. Its terms require expertise.

Between those two lies a chasmβ€”and 7,403 applications fell into it.

The uncomfortable truth: AI can write your backend, but it can't own your security posture. That responsibility remains human. It requires understanding access control, database policies, and the difference between "it works" and "it's safe."

Cloud security isn't a feature you bolt on later. It's a decision you make before the first user signs up.

The Closing Thought

The researchers didn't exploit a vulnerability.

They exploited a patternβ€”a predictable, repeatable, AI-generated pattern that said: "We didn't know we needed to lock this door."

The fix is simple. The lesson is expensive.

Enable RLS. Write policies. Test like an attacker.

And the next time an AI offers to build your app in four minutes, ask it one question:

"Did you enable Row Level Security?"

If it doesn't know the answer, neither do you.

Did this help you understand the Lovable/Supabase exposure? Share it with someone building their first AI-generated app. The knowledge gap is the vulnerability.

Reference Research Report:
https://www.crissyfield.de/research/lovable-en/

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.