Service 08 · Supabase security
Supabase multi-tenant security audit
Row-level security is either correct or it is not, and the difference is usually one policy that was never tested from the other side.
Fig. 08 — Supabase security
What this usually looks like
- A policy that works in the dashboard and fails through the API.
- A service key in client-side code.
- Tenant boundaries enforced in the application and not in the database.
- A query that returns another tenant's rows under a specific filter.
What you get
- Every table and policy, tested from an unprivileged position.
- Any path that reaches data belonging to another tenant.
- A correction for each, with the reasoning.
- A regression check, so a future change cannot quietly reopen it.
Analysed multi-tenant isolation and reliability on a production Supabase build, and packaged the findings with reproduction steps.
Questions
Do you need production access?+
No. A staging clone with representative policies is enough, and safer.
Is this a penetration test?+
No. It is a focused review of authorisation and isolation, not a general attack simulation.
What if we find nothing?+
Then you have written evidence that the policies hold. That is worth having before a client asks.
Next step
Tell us what is not working
Describe the problem in a few lines. You get a plain answer about whether it is worth fixing and what it would take, before any money changes hands.
Start a conversation →