I Audited 10 Lovable Apps. Here's What I Found

Between January and March 2026, the PolyDefender team ran security assessments on ten Lovable applications in production. All ten were real products with real users — SaaS tools, marketplaces, AI-powered productivity apps, and data dashboards. The developers ranged from first-time non-technical founders to experienced engineers using Lovable to accelerate delivery. Here is what we found.

Background and Methodology

Each audit combined a PolyDefender automated scan with a manual review of the application's API endpoints, database configuration, and key management practices. Apps were scanned at their production URL without access to source code first, then with source code access for deeper analysis. All findings were de-identified with permission from the development teams.

We categorized findings across five domains: credential exposure, database access control, endpoint authorization, dependency safety, and deployment hygiene.

Finding 1: Exposed Credentials in 7 of 10 Apps

Seven of the ten applications had at least one API key, secret, or privileged token in a client-visible location. The most common pattern was a Supabase service_role key in an environment variable that had been prefixed with NEXT_PUBLIC_ during early development and never moved server-side. In three cases, the key was still in the compiled JavaScript bundle deployed to production.

The blast radius varied. In two apps, the exposed key was a low-privilege publishable key with limited damage potential. In five apps, it was a key that could read all data, send emails to arbitrary addresses, or make charges against a connected payment account. In one case, the exposed key had been used by an automated scanner to enumerate approximately 40,000 user records before the audit.

Finding 2: Missing or Permissive RLS in 6 of 10 Apps

Six apps had at least one Supabase table with RLS disabled or with a policy so broad it was functionally equivalent to no policy at all (USING (true) was the most common pattern, meaning every authenticated user could access every row). In three of those six apps, the open table contained user PII — email addresses, profile data, or order history.

The most common explanation from developers was that RLS had been disabled to speed up prototyping and the re-enablement had been deferred. In two cases, the developer was unaware that the anon key, which they considered "safe to expose," gives unauthenticated users direct database access when RLS is off.

Finding 3: IDOR in 9 of 10 Apps

Nine of the ten applications had at least one API endpoint that trusted a user-supplied identifier — a userId, itemId, or organizationId in the request body or URL — without verifying on the server that the requesting user owned the referenced object. This is the definition of an Insecure Direct Object Reference (IDOR) vulnerability.

In Lovable-generated code, this pattern appears because the scaffolded CRUD handlers receive the ID from the frontend state and pass it directly to a Supabase query. The query runs successfully because Supabase itself does not know the ID was tampered with — that check has to happen in the application layer or through an RLS policy.

The fix in most cases was to replace the client-supplied ID with auth.uid() in the Supabase query, or to add a WHERE user_id = auth.uid() condition to every handler that reads user-owned data.

Finding 4: Risky Dependencies in 4 of 10 Apps

Four apps contained npm packages added during AI-assisted refactoring sessions that had characteristics associated with supply-chain risk: very recent first-publish dates (under 30 days old at time of audit), no previous download history, or names that closely resembled well-known packages with one character changed (typosquatting candidates).

None of the four were confirmed malicious, but two contained postinstall scripts that executed code during npm install — a pattern that legitimate packages rarely use and malicious packages frequently do.

What the Fastest-Fixed Teams Did

The teams that resolved their critical findings fastest shared a common approach: they used the PolyDefender scan report as a prioritized work queue, assigned one engineer to each finding with a 24-hour SLA, and re-ran the scan after each fix to confirm resolution rather than relying on self-assessment.

The teams that took longest had the opposite pattern: they treated the scan as a one-time event, fixed the most visible issue, and marked the project "secure" without verifying the remaining findings or setting up ongoing monitoring.

The Takeaway

Lovable makes it genuinely fast to build production-quality features. The security gaps we found were not caused by Lovable — they were caused by the universal tendency to defer security work during fast iteration. The finding that sticks with us from this audit series: nine out of ten apps had at least one exploitable vulnerability that could have resulted in a data breach within the first week of going live. None of the developers knew about it. Continuous scanning is not a nice-to-have for AI-built apps. It is table stakes.