I built a free scanner that checks if your Lovable/Bolt/Base44 app is leaking data — here's why it matters

If you've built anything with Lovable, Bolt.new, Base44, or Replit Agent in the last year, there's a good chance your app talks to Supabase behind the scenes. And there's a real, documented chance that talk is happening a little too openly.

The pattern nobody warned you about

AI app builders are extraordinarily good at wiring up a database connection. What they're not consistently good at is turning on the permission layer that decides who is allowed to read that database once it's live.

This isn't a rumor. It's been measured, more than once, at scale:

• CVE-2025-48757: a security researcher scanned 1,645 live Lovable projects and found 170+ of them — about 1 in 10 — had Row Level Security misconfigured on Supabase, exposing user data to anyone who knew where to look. It scored 9.3 out of 10 on the CVSS severity scale.
• Symbiotic Security scanned 1,072 real vibe-coded apps in a three-month study and found 98% had at least one security issue, 16% of them critical.
• Escape.tech audited 5,600 production apps and found over 2,000 vulnerabilities and 400+ exposed secrets.
• CodeRabbit's analysis of AI-generated pull requests put the number at 45% containing a security weakness.
• In April 2026, a second, separate Lovable incident let any free account read other users' project source code, database credentials, and chat history — a reminder that this isn't a one-time fluke, it's a recurring category of mistake.

The root cause is almost always the same: Supabase requires you to explicitly turn on Row Level Security and write policies for who can read what. AI builders optimize for "it works" — and a database with no RLS does work, right up until someone else notices.

I tested this on my own stuff first

Before writing a line of the tool, I ran it against one of my own projects, Sentinel Oracle, deliberately leaving a test table (waitlist) without RLS enabled, seeded with fake emails.

The scan found it in seconds:

{
  "overall_severity": "PRIVATE",
  "tables_discovered": 40,
  "tables_with_leak": 1,
  "details": [
    {
      "table": "waitlist",
      "severity": "PRIVATE",
      "rows_exposed_sample": 2
    }
  ]
}

Then I paid for the detailed report — with a card and, separately, with USDC on Base to test both flows — and got back a plain-language explanation of the finding plus the exact SQL to fix it, generated automatically, without the AI model ever seeing the actual leaked values (only metadata: table name, column names, row count).

What I built: TrustBoost's free scanner

It's simple on purpose:

1. Paste your Supabase project URL and its public anon key (already sitting in your own app's browser code — nothing you have to dig for).
2. It checks, read-only, whether common tables and storage buckets respond without authentication.
3. If something's open, you get a severity score for free. A detailed report with the exact fix costs $49 — payable by card or USDC.

It never writes to your project, never stores the data it finds, and only reads what any visitor to your app could already read.

Try it on your own project:

• Lovable: https://api.trustboost.dev/check/lovable
• Bolt.new: https://api.trustboost.dev/check/bolt
• Base44: https://api.trustboost.dev/check/base44
• Replit Agent: https://api.trustboost.dev/check/replit
• Or just the general scanner: https://api.trustboost.dev/free-scan

The honest caveat

A clean scan isn't a certified security audit — it checks common table names and public storage buckets, not your full schema or business logic. If it comes back clean, that's good news, not a guarantee. If it doesn't, you'll know exactly what to fix and why it matters.

Built solo, feedback welcome — especially from anyone who's hit this exact problem shipping fast with AI tools.