RLS isolation review

Prove your row-level security actually isolates tenants.

Most Supabase data leaks are not exotic. They are a table with RLS switched off, a policy keyed on a claim the user can edit, or a view that quietly serves rows past the policy. We audit that configuration and prove tenant isolation at the database, then commit the test that keeps it proven.

The engine

rls-audit

A command-line auditor for Postgres and Supabase row-level security. It connects to the database URL you give it and prints to your terminal. No account, no upload, no telemetry. Apache-2.0, and not yet published. When it is, the install line and the repository appear here together.

detect

A read-only scan of the catalogues. It flags RLS left off on an API-exposed table, a policy trusting client-editable metadata, a definer function with no pinned search path, and seven more configuration faults, in seconds.

probe

One live table, read-only. It signs in as tenant A and checks that tenant B’s rows are invisible. If tenant B owns no rows to hide, it reports the probe skipped rather than green, so an empty table is never counted as isolated.

isolate

A seeded suite across every table you declare: read, update, delete, and a smuggled insert, run as one tenant against another. It proves tenant A can see its own row before it trusts that A cannot see B’s. Every write it makes is inside a transaction that is always rolled back.

A clean scan is necessary but not sufficient. The catalogue cannot prove a policy’s logic is right, only that the guard rails are there. The isolation probes prove the logic.

The paid review

Authorized RLS and Auth Isolation Configuration Review

A fixed-scope review, delivered within 48 hours of the review starting, once you have signed the authorisation and provisioned a staging or branch database clone. We run one engagement at a time, so we agree a start date rather than promise an instant one. It is a configuration review and isolation test. It is not a penetration test.

A written report

Every finding by severity, in plain language, with the exact fix. Scoped to the schemas we agree, at a point in time.

A test suite in your repo

A reproducible FORCE-RLS isolation suite committed to your repository, so the proof lives with your code and re-runs on demand.

A remediation pull request

On the remediation tier, we fix the findings, prove the suite goes green, and open the pull request for your team to review and merge.

All writes are confined to the disposable clone you provision and are rolled back. Nothing is persisted, and we never touch your production database. Our total liability is capped at the fees you pay.

Pricing

Fixed scope, fixed fee.

Configuration review

start here

A$700

per review

The scan, the isolation proof, the written report, and the test suite committed to your repo. Founding rate of A$350 to A$450 for the first two clients, in exchange for a testimonial. Two, not more: we hold intake there until our professional indemnity cover is bound.

Review and remediation

A$1,500 to A$2,500

per engagement

Everything in the review, plus we write the fixes, prove the suite goes green, open the remediation pull request, and re-test.

All prices in Australian dollars. Any GST that applies is shown on the invoice. Invoiced through Xero and paid by bank transfer.

What we check

The faults that leak Supabase data.

Critical
RLS disabled on a table granted to the anon or authenticated API roles.
Critical
A policy that authorises on user_metadata, which the end user can edit.
Warning
RLS disabled on a table that is not granted to the API roles, so only a later grant exposes it.
Warning
RLS enabled but not FORCEd, so the owner and definer functions bypass it.
Warning
RLS enabled with no policies at all, a deny-all that is usually unfinished.
Warning
A policy whose USING clause matches every row.
Warning
A policy whose WITH CHECK clause accepts any written row.
Warning
A SECURITY DEFINER function with no pinned search_path.
Warning
A view that does not set security_invoker, so it reads with its owner’s rights rather than the caller’s.
Info
auth.uid() not wrapped as (select auth.uid()), a table-scan cost.

Scope and honesty

What a clean result does and does not mean.

We check the row-level security and auth-isolation configuration of the schemas we agree, and we prove tenant isolation at the database layer. That is the whole of it.
We do not test your application code, your API gateway, or anything above the database. We are not a penetration test and do not claim to be.
A clean result is evidence about the tables and policies we saw, at the time we saw them. It is not a guarantee that your application is secure.
A signed authorisation comes before any access. You can withdraw it in writing at any time.
Our total liability is capped at the fees you pay. Nothing in that cap limits any liability that cannot lawfully be limited, including the non-excludable rights you have under the Australian Consumer Law.

Get the tool and the occasional note

The command line auditor will be free and will need no sign-up. Leave an email if you want the release notes and the technical write-ups as they land.

Bring us the database. We’ll bring the proof.

A signed authorisation, a staging clone, and an agreed start date. You get the report and the test that keeps it true.

Enquire about a review