Security · Authorisation Model Review
Can tenant A read tenant B's row? We find out properly.
Multi-tenant isolation testing against your real schema and policies. Most testing proves you cannot log in as someone else. This proves that once you are legitimately logged in, you still cannot reach what is not yours.
Authorisation Model Review
- Typical length
- 1 week
- What you get
- 7 written deliverables, listed below
- What decides the number
- Number of roles, number of tables under policy, and whether there is a service-role key path that bypasses row-level security. Applications with one admin role are quick; ones with delegated per-organisation permissions are where the time goes.
- Scoping
- One call, then a written scope. We say no when it is not ours.
Contact salesGet a quote
01 The terms
Quoted per project, after a call. We do not publish a band for this, because a number without a scope is a guess and you would have to unpick it later anyway.
Tell us what the work has to do and when it has to be done, and you get the scope and the number in writing — or a straight answer that this is not ours.
03 The problem
Authentication gets tested. Authorisation usually does not. The result is an application where every login works exactly as designed and one unparameterised query, one missing policy, or one service-role key on the client exposes every tenant to every other tenant.
Row-level security written after the schema rather than with it is the usual cause. Policies added late are policies nobody can reason about, and the gaps are invisible until somebody goes looking.
04 What you get
- Per-table, per-role matrix of what is actually reachable, tested against a live instance
- Cross-tenant read and write attempts from a legitimately authenticated session
- Row-level security policy review against the schema, not against the documentation
- Service-role and key-handling audit — anything that bypasses policy, and where it is exposed
- Storage and file-access isolation, which is usually where it leaks
- API and edge-function authorisation checks
- Written findings with the failing query for each one, so a fix can be verified
05 How it runs
- Day 0
- Scope and written authorisation. Access to a staging instance with representative data — never production.
- Days 1–3
- Policy and schema review, then the reachability matrix built by testing.
- Days 4–5
- Findings written up with reproductions, then a call.
06 Whether this is for you
This is for you if
- Postgres and Supabase applications using row-level security
- Any B2B product where two customers share a database
- A team that inherited an application and does not know what its policies allow
- You are about to sign an enterprise customer who will ask this question
This is not for you if
- Any system you do not own or have written authorisation from the owner to test. We ask in writing before we start and will decline without it.
- Stacks other than Postgres. This offer is built on Postgres row-level security — MySQL, Mongo and DynamoDB tenancy models are a different problem and we do not cover them.
- Testing against production data. Staging with representative data, always.
- Full web application penetration testing — this is one deep slice, not broad coverage
- Compliance certification
07 Proof
Fabricport runs four role-scoped portals — public catalogue, buyer, supplier and admin — over row-level-secured Postgres. We write these policies alongside the schema because policies bolted on afterwards are the ones that leak.
08 Questions
Why not just run a scanner?
A scanner does not know that order 4471 belongs to a different tenant. Authorisation bugs are semantic — they need somebody who has read your schema and understands what the data means.
What happens to our data and our firmware?
NDA signed before you send anything. Everything you give us — images, captures, schemas, credentials — is held encrypted, never shared outside the engagement, and deleted 30 days after the report unless you ask us to keep it for a retest. Credentials are staging-only and we ask you to rotate them when we finish.
Do you need production access?
No, and we will decline it. A staging instance with representative data is what we work against.
Next 1 week
Authorisation Model Review
Tell us what the work has to do and when it has to be done. You will get a person who has read it, not a sequence.