The Lovable Security Crisis: What Went Wrong

In late 2025, security researchers discovered that over 170 applications built with Lovable had exposed their users' data to the public internet. The total impact: approximately 18,000 users whose personal information — emails, passwords, payment details, and private messages — was accessible to anyone who knew where to look. This was not a sophisticated attack. It was a misconfiguration that Lovable's platform should have prevented.

What Happened

Lovable connects to Supabase for backend storage and authentication. Supabase uses a feature called Row Level Security (RLS) to control which users can read and write which rows in the database. When RLS is enabled and configured correctly, users can only access their own data. When RLS is disabled or misconfigured, every user can read every row in every table.

Lovable's AI code generator was not consistently enabling RLS on the tables it created. In many cases, the tables were created with RLS disabled entirely. In other cases, RLS was enabled but the policies were too permissive (allowing any authenticated user to read all rows). The result: any logged-in user of one Lovable app could query the database and retrieve every other user's data.

The Root Cause

The root cause was not a bug in Supabase. Supabase's documentation is clear about the need for RLS policies. The root cause was that Lovable's AI did not consistently generate the correct security configuration. The LLM optimized for getting the app working — and an app without RLS works perfectly from a functional perspective. The data flows correctly, the UI renders properly, and the developer sees a working product.

Security is a constraint that does not produce visible output. If your access control is broken, the app still works — it just works for everyone, including attackers.

The Scale of the Problem

We analyzed a sample of 50 Lovable-generated applications. The findings:

• 34 out of 50 (68%) had at least one table with RLS disabled entirely
• 12 out of 50 (24%) had RLS enabled but with overly permissive policies
• Only 4 out of 50 (8%) had properly configured RLS on all tables
• 22 out of 50 (44%) exposed their Supabase anon key in client-side code

The Supabase anon key is designed to be public, but only when combined with proper RLS. Without RLS, the anon key becomes a skeleton key to the entire database.

Lovable's Response

To their credit, Lovable responded quickly. They added a built-in security scanner that checks for common vulnerabilities. But their own testing shows it catches only 66% of security issues. That means one in three vulnerabilities still ships to production.

A 66% detection rate would be unacceptable for any other quality metric. Imagine a spell checker that catches two-thirds of typos, or a test suite that passes two-thirds of the time. Security is binary in its consequences: one missed vulnerability is enough for a breach.

What to Check in Your Lovable App Right Now

If you have built an app with Lovable, do these checks today:

1. Check RLS Status

Open your Supabase dashboard. Go to the Table Editor. Click on each table. Look for the RLS badge. If any table shows 'RLS disabled,' you have a problem.

2. Review RLS Policies

Even with RLS enabled, the policies matter. A policy that says 'allow all' is the same as no RLS. Each table should have policies that restrict access based on the authenticated user's ID.

3. Check Your API Keys

Open your browser's developer tools on your deployed app. Search the JavaScript bundles for your Supabase URL. If you find both the URL and the service_role key (not the anon key), you have a critical vulnerability. The service_role key bypasses all RLS policies.

4. Run a Security Scan

Manual checks catch obvious issues. Automated scanning catches subtle ones: broken auth flows, IDOR vulnerabilities, missing input validation, XSS vectors. Run your app through NeuroStrike's vibe scan. It was built specifically for this class of application and catches the patterns that Lovable's built-in scanner misses.

The Bigger Picture

The Lovable security crisis is not unique to Lovable. It is a preview of what happens when AI tools generate code without security constraints. Every vibe coding platform has the same fundamental problem: the AI optimizes for functionality, and security is a non-functional requirement that does not produce visible output.

We are not saying to stop using these tools. We are saying to add a security layer. The tools are getting better, but "66% detection" is not good enough when user data is at stake.