Supabase review · Assessment
Can one user read another user’s rows in your Supabase?
If an AI tool or tutorial wrote your Supabase RLS policies and nobody read them: in one week, a table of what each role can read and write, tested by queries.
FormatWritten assessment
Timeline1 week
PricingFixed-price assessment · hourly work
Proof3 case studies
The assessment in 4 parts
01 · Signs you need it
If two of these apply, this is a good fit.
- The RLS policies were generated or copied from a tutorial and nobody has read them through
- You cannot say with confidence whether one user can read another’s row
- A key that was meant to stay on the server shows up somewhere in the client
- A storage bucket has been public “temporarily” since week one
- An edge function runs with the service role because that was the only way to make it work
02 · What you get
The week ends with a document that lists:
- An access table that shows, for every table and every role, what that role can see and what it can change. We build it by running queries, so it reflects what the policies actually allow.
- Tables with no policy at all, and tables where RLS is on but the policy in effect lets everything through.
- Keys and secrets we found in the client bundle or the repository, marked where they need to be rotated immediately.
- Public storage buckets, their path rules and edge functions that bypass the policies because they run with elevated rights.
03 · How we decide
STEP 01Keys are checked before any policy.A service role key bypasses row-level security entirely. If one has already reached the client, the policies protect nothing and the access table loses its meaning.
STEP 02We run each policy under each role.Each policy is checked with a query run as an anonymous user, as the row’s owner and as the owner of a different row. A policy that returns more rows than it should raises no error.
STEP 03Permissive policies add up.They combine with OR, so a new policy can only widen what the others allowed. The database applies all of them together, which is why we review them as a set.
STEP 04We add checks to the build.The build fails when a table appears without a policy, a bucket turns public or a key pattern lands in the bundle. Whether a policy does what its name says is still something a person has to read.
04 · If we find nothing
Then you get the access table as evidence that each role reads and writes only what it should, and a check in the build that fails if that stops being true.
Proof
Where we’ve done this before
Case study 15 · Business systemsSoldIn a white-label meeting product for healthcare and finance, the right to open a file depended on a chain through a meeting, a document, its version and a signature. One condition on a row could not express that.Read the case study →Case study 08 · Marketplace506 routesOne codebase for five kinds of user, where a vendor’s operator and a fleet carrier’s operator get different rights because a permission is resolved from user type and role together. The backend validates it again, since separating routes in the client only organizes the interface.Read the case study →Case study 09 · Identity1 working dayA passport system where the server catches duplicate applications before anything is accepted, and the national registry sits behind keys, digest authentication, single-use tokens and an IP allow-list, so one stolen key is not enough to get in.Read the case study →WritingUpload to S3 with a signed URL instead of through your backendSigned upload links scoped to one object and one method, expiring in minutes, with a lifecycle rule that cleans up the orphaned files they leave behind.Read the post →
FAQ
Questions about this service
One week from the day we get access to the project and the repository. The first two days go on the inventory, and the rest of the week on running the checks role by role.
Read-only access to the Supabase project and the repository. Production data isn’t needed, because the policies are tested against test rows.
No. This review covers data access only and takes a week. If you also need to know what is urgent, what is expensive and what to rewrite across the whole app, that is the two-week app audit and rescue.
If we find a leaked service role key or a policy that exposes another user’s rows, we tell you that day, before the document is finished. Fixing it is not part of the review, and we charge for that work by the hour.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.