Try the demo Check my app free

For Lovable apps

Built it in Lovable? Check who else can read its data.

Lovable apps usually keep their database rules in supabase/migrations in the connected GitHub repo. We rebuild that database in a lab, read it as a stranger, and hand you a fix that has already passed the proof.

Free for your first appReads your public repo onlySee a sample report

Independent: PatchLabs is not affiliated with Lovable.

your-lovable-app/
├─ src/
│  ├─ integrations/supabase/
│  │  └─ client.ts   public key, by design
│  └─ pages/
└─ supabase/
   └─ migrations/    ← we rebuild from here
      ├─ …_init.sql
      └─ …_profiles.sql
A typical layout. Yours may differ; what matters is the supabase/migrations folder.

Will it work?

Check this before you paste your repo.

Works today when

  • Your project is connected to GitHub through Lovable’s GitHub integration
  • The repo is public (private repos come with our GitHub App)
  • The database is Supabase, with a supabase/migrations folder

Not covered yet

  • Private repos, until our GitHub App ships
  • Database changes that exist only in Supabase and never reached a migration file
  • Anything outside the database rules, such as edge functions

The common leak

The rule that says “everyone can read profiles”.

A common way a Lovable app leaks: a read policy written so the profile page works for everyone, on a table that also holds emails and phone numbers. Anyone with the app’s public key can then read every row. The fix keeps what the app needs and closes the rest.

318public Lovable and Supabase apps rebuilt1
106let the wrong people read personal data1
1in 4exposed real personal data1
  1. PatchLabs lab study, Nov 2026. 436 public Lovable and Supabase repos run (from a random sample of 500); 318 built a working database in the lab. 106 of 318 (33%): 70 to anyone with the public key, 36 to anyone who signs up. About 1 in 4 (25–28%) after removing businesses’ own public contact details. The study doesn’t separate Lovable from other Supabase projects. Methodology.
the pattern, and the proven fix (our demo app)
-- before: anyone with the public key reads every profile
create policy "Profiles are viewable by everyone"
  on public.profiles for select using (true);

-- after: each user reads only their own profile
create policy "Users can view own profile"
  on public.profiles for select using (auth.uid() = user_id);

Illustrative SQL. Your report contains the real migration for your tables, and it only counts as proven once the anonymous visitor and the signed-in stranger are denied and the owner still reads their own rows.

How the fix lands

From proven fix to your live app.

Lovable syncs both ways with your GitHub repo, so a file committed on GitHub shows up in your Lovable project. Whether Lovable then applies a new migration file to your database automatically is something we haven’t verified for every setup, so check Lovable’s docs and confirm the result.

We never push to your repo or touch your database. Nothing changes until you, or your engineer, applies the migration. Automatic pull requests need our GitHub App, which is coming.

  1. Get the fix

    Download the migration from your report, or use “Commit this file on GitHub”.

  2. Apply it to the database

    Depending on your setup: let Lovable apply it, paste the SQL into your Supabase project’s SQL editor, or ask Lovable’s agent to apply that migration. If your project uses Lovable Cloud rather than a Supabase project you connected yourself, check Lovable’s docs for how database changes are applied.

  3. Make sure the repo matches

    If you applied the SQL by hand, keep the migration file in the repo too, so the next change builds on it.

  4. Re-check

    Run the check again. It confirms the leak is closed in what the repo now describes.

Questions

Lovable questions.

Something else? Email the founder.

Supabase appsBolt appsReplit appsCursor apps
Isn’t Lovable’s own security scan enough?

Use it: it’s built in and catches common problems. It tells you a rule looks risky. We rebuild the database, test as an anonymous visitor, a signed-in stranger and the owner, and prove the fix before you apply it. They work well together. Comparisons.

Do you need access to my Lovable account or Supabase project?

No. We only read the public GitHub repo. We never ask for your Supabase password or service-role key, and checks never connect to your live app or database.

My repo is private. What can I do?

Private repos need our GitHub App, which is coming. If you’d rather not make the repo public, email us and we’ll tell you when it’s ready.

Will the fix break my app?

Every fix must keep the owner reading their own rows, and the report includes a risk note about anything that could behave differently, such as a logged-out page that relied on the old rule. Read it before you apply.

Is PatchLabs part of Lovable?

No. PatchLabs is independent and not affiliated with Lovable. We work with apps built on Lovable because their code lives in GitHub.

Free check

Can a stranger read your users table? Find out in minutes.

You’ll get the leaks, the fix and the proof on one page. How it works.

Check my app freeSee a sample report