Set Supabase up
and lock it down.
Supabase is stood up in an afternoon, and that is precisely the risk. The database is there, the login works, and then months later it turns out every logged-in user can reach everybody's table. I set it up the way it is meant to be: permissions at database level, migrations in version control, and nothing important in the browser.
What goes wrong in practice.
Row-level security is off
Or it is on with a policy that amounts to 'anyone logged in may do anything'. The anon key sits in the browser, so that is an open door.
The front end guards the permissions
The button is hidden, but the endpoint behind it still works. Anyone who opens the network tab gets in.
Columns were changed by hand
Changes made straight in the dashboard editor. No migrations, so no second environment and nothing to roll back.
The service role key leaks
That key bypasses every permission. If it sits in client-side code or an unprotected function, the whole security setup is theatre.
No tested backups
A backup that has never been restored is an assumption, not a backup. It usually comes out at the worst moment.
Queries get slow
Without indexes and with too many separate requests per page, the number of database calls climbs until the app visibly stutters.
From loose tables to a foundation.
Review what is there
Schema, policies, keys and what data is actually in it. You get a list of what is a security risk and what is only messy. That first scan is free and meant as a first impression, not a full security audit.
Permissions at database level
Row-level security per table, policies per role, and the service role server-side only. So the permissions hold even if someone skips the front end.
Migrations and environments
Every schema change as a migration in Git, plus a separate test and production environment so you can change things without touching your customers.
What connects to it
Auth with roles and password recovery, storage with permissions, edge functions for what does not belong in the browser, and backups that have actually been restored.
- ✓Row-level security per table and per role
- ✓Migrations in Git, test and production environments
- ✓Keys out of the client, service role server-side
- ✓Auth with roles, recovery and sessions
- ✓Backups that are tested, not assumed
The first opinion costs you nothing: send me the repository or a link and I will tell you honestly whether building on beats starting over.
Can you just review the security?
Is Supabase GDPR-proof?
What if I want to leave Supabase later?
Do you work with Firebase or a self-hosted database too?
Tell me what you
want to build.
A half-hour call. You get an honest answer about what it costs, how long it takes and whether building it is smart at all.
Have your current site or tool scanned
You do not have to want to buy anything yet. Send what you have and I will tell you honestly what I would keep, what I would replace and whether that is worth the investment. Including when the answer is that you are better off doing nothing.
The scan is a first impression, not a security audit.
- 01Send a link to your site, your tool or your repository
- 02I look at speed, structure, data and security
- 03Usually within two working days you hear what I would replace and what that costs