For Replit apps
On Replit with Supabase? We can test it. Here’s what fits.
Many Replit apps use Replit’s own database instead of Supabase. We test Supabase row level security, so here’s how to tell whether your app fits before you paste anything.
Independent: PatchLabs is not affiliated with Replit.
Fits: Supabase from a Replit app
Your app talks to Supabase, and the schema is in supabase/migrations in a public GitHub repo. The leak lab and the key scan both run.
Not yet: Replit’s built-in database
No Supabase migrations to rebuild from, so the leak lab can’t run. The key scan of your code and git history still does.
supabase/migrations folder in your repo.Will it work?
Check this before you paste your repo.
Works today when
- The app uses Supabase, with its schema in
supabase/migrations - The code is pushed to a public GitHub repo, for example from Replit’s Git pane
- Access control uses Supabase RLS
Not covered yet
- Apps on Replit’s built-in database or another backend
- Private repos, until our GitHub App ships
- API routes and server code that decide who sees what
The common leak
Where the leak lives depends on your database.
With Supabase, the browser often reads the database directly with the public key, so RLS policies decide who sees what, and that’s what we test. With a server-side database, your API routes make that decision instead. We don’t test API routes yet, so we won’t pretend to.
No Replit-specific numbers yet. Our study sampled public Lovable and Supabase repos, so we don’t publish figures for Replit apps. The access rules work the same way on any Supabase database, which is what we test.
-- before: anyone who signs up reads every booking
create policy "Authenticated can read bookings"
on public.bookings for select to authenticated using (true);
-- after: users read their own bookings only
create policy "Users read own bookings"
on public.bookings 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.
For a Replit app on Supabase, the fix is applied to your Supabase project, not to Replit. How your deployment picks up schema changes is something to check in your platform’s docs.
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.
Get the fix
Download the migration from your report, or commit it on GitHub in one click.
Apply it to Supabase
Paste the SQL into your Supabase project’s SQL editor, or use
supabase db pushif you work with the Supabase CLI.Pull the change into Replit
Keep the migration file in your repo and pull it into your Repl, so future changes build on it.
Re-check
Run the check again to confirm the leak is closed.
My Replit app uses Replit’s database. Can you check it at all?
The key scan runs on any public repo, so exposed AI, payment and database keys in your code and git history are still found. The leak lab needs Supabase migrations, so it can’t run on that app yet.
How do I get my Repl onto GitHub?
Replit has Git built in, so you can connect a GitHub repo and push. Check Replit’s docs for the current steps.
Do you need access to my Replit account?
No. We only read the public GitHub repo.
Is PatchLabs part of Replit?
No. PatchLabs is independent and not affiliated with Replit.
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.