Try the demo Check my app free

For Supabase apps

Your row level security, tested as a stranger.

Supabase gives anon and authenticated access to new tables in public by default, so your RLS policies are the only thing standing between your public key and your rows. We rebuild your database from supabase/migrations and test those policies as three different people.

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

Independent: PatchLabs is not affiliated with Supabase.

applying a PatchLabs fix with the Supabase CLI
# put the migration from your report in the repo
mv ~/Downloads/*_patchlabs_leak_fix.sql supabase/migrations/

# see which migrations the linked project has applied
supabase migration list

# apply the pending ones to the linked project
supabase db push
Standard Supabase CLI commands. Review the migration before you push it.

Will it work?

Check this before you paste your repo.

Works today when

  • Your schema lives in supabase/migrations in a public GitHub repo
  • Access control uses RLS with auth.uid() and JWT claims
  • Personal data sits in tables in the public schema

Not covered yet

  • Schema changes made only in the dashboard and never pulled into a migration
  • Custom auth that doesn’t go through Supabase Auth claims
  • Storage policies and edge functions, which aren’t proven in the lab

The common leak

Three ways RLS lets the wrong person in.

RLS never enabled on a table (with the default grants, it’s readable through the API). A policy that’s always true. And a policy that checks someone is signed in instead of checking the row is theirs, so one free sign-up unlocks everyone’s data. We test for the effect of all three, not just their shape.

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.
signed in is not the same as “owns this row”
-- before: any signed-in user reads every order
create policy "Signed-in users can read orders"
  on public.orders for select
  using (auth.role() = 'authenticated');

-- after: users read only their own orders
create policy "Users read own orders"
  on public.orders for select to authenticated
  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.

The fix is a normal Supabase migration, timestamped to run after your existing ones. Ship it exactly as you ship any other migration.

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. Add it to supabase/migrations

    Download it from the report, or use “Commit this file on GitHub” to open GitHub’s new-file page with the path and SQL filled in.

  2. Apply it

    With the CLI, supabase db push applies pending migrations to your linked project. If you use Supabase’s GitHub integration with branching, it can run migrations from your repo; check your project’s settings and Supabase’s docs for when that happens.

  3. Or paste it, then commit it

    Running the SQL in the dashboard’s SQL editor works too. Commit the file as well, so your repo and database stay in step.

  4. Re-check

    Run the check again, or let the schedule do it.

Questions

Supabase questions.

Something else? Email the founder.

Lovable appsBolt appsReplit appsCursor apps
How is this different from the Security Advisor?

The Advisor lints your live project’s configuration, and it covers health and performance too. Keep using it. We rebuild the database from your repo and test behaviour as real identities, then prove a fix. How our finding IDs map to its lints.

Do you need my service-role key or database password?

No. We never connect to your project. Everything runs on a disposable copy built from your migrations.

What do you seed?

Fake rows owned by two test users, with fake values such as x@example.com in required columns. No real data, ever.

Can a fix use views or column grants instead of policies?

Yes. Rows and personal columns are tested separately, so a fix that keeps a table publicly readable but hides its personal columns can pass.

Are you affiliated with Supabase?

No. PatchLabs is independent. We copy Supabase’s default roles and grants in our lab so the test matches how Supabase behaves.

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