Audit service
Your policies say they isolate tenants. Here is the test that proves it — and the patch when they don’t.
Row-level security is the one control in a multi-tenant app where being almost right looks exactly like being right. A policy that is missing, scoped to the wrong column, or silently bypassed by asecurity definer function returns data and no error.
This is a five-day, fixed-price audit of that boundary: every policy read and classified, cross-tenant tests written against your own application paths, and patches delivered as a pull request you can review.
$1,500 — fixed scope, five working days, written only. Service terms apply.
Your stack stays yours. The audit is against the database, not the framework — Next.js, SvelteKit, Rails, Go, anything that talks to Postgres or Supabase. You do not change a line to be audited, and the patches are migration files your team reviews like any other.
Why this is a service and not a scanner
In late September 2026, UpGuard researchers reported finding more than 16,000 Supabase databasesexposing readable tables with personal data, passwords or auth tokens. They analysed roughly300,000 domains for the signature of a Supabase project, and attributed the exposure to “poor application security configurations, including missing or ineffective row-level security policies and misuse of public keys.”BleepingComputer, September 2026.
A scanner tells you a table looked readable from outside. It cannot tell you whether your application leaks across tenants — because that depends on your policies, your query paths, and the functions that run with raised privileges. That gap between “a rule exists” and “the rule holds under my own code” is the entire service.
What you get, in five working days
Every policy, read and classified.
A report listing each RLS policy and each table that has none, with a verdict: enforced server-side, enforced but bypassable, or absent. Not a scanner score — the SQL, quoted, with the reasoning next to it.
Cross-tenant tests, as code you keep.
Tenant A tries to read, update and delete tenant B’s rows through your own application code paths. The tests are committed to your repository, so the next policy regression fails CI instead of leaking data.
Patches as a pull request.
The missing or wrong policies written as a reviewable diff against your migrations — not a document you have to translate back into SQL.
An evidence pack.
Before/after output of the same tests, so the fix is provable to a customer, an auditor or a security questionnaire — the part a scanner cannot give you.
What this is not
- It is not a penetration test.
- No exploitation against live systems, no privilege escalation, no network boundary. It reads schema, policies and your application’s query paths.
- It is not a compliance certificate.
- It will help you answer a security questionnaire about tenant isolation. It does not make you SOC 2, HIPAA or GDPR compliant, and does not claim to.
- It does not touch production data.
- You run it against a clone or a restore. We never ask for production credentials, and the tests are written to read rows, not to export them.
- It is not a subscription.
- One fixed price, five working days, one deliverable. No retainer, no seat, no per-tenant meter.
Four steps, written throughout
- 1. You send a schema dump and the policies. A clone of the database structure, plus the migrations that create your policies. No data, no production credentials.
- 2. We write the attack before the report. The cross-tenant tests are written first, against your real query paths, so the report describes what was demonstrated rather than what was suspected.
- 3. Report, patch and evidence pack. Delivered within five working days, in writing, in your repository.
- 4. Ten working days to ask questions. Written answers to anything in the report, at no extra charge. After that window the audit is yours to keep and to re-run.
This is a new offer, and this page says so
There are no testimonials here because there are no customers yet. What can be checked instead is the work behind it: thirteen published pages on tenant isolation, RLS and audit logging, three live demo applications whose isolation is exercised by their own test suites, and a licence published before you pay anything.
If that is not enough evidence to buy an audit, the honest answer is not to buy one yet — read the material, run the free tests against your own database, and come back when the gap matters.
Related: RLS in SvelteKit + Postgres ·Supabase RBAC and RLS ·deployment service
Start with the schema, not a call.
Send the schema dump and the migrations that define your policies. You get a written answer within one working day on whether the audit is the right thing to buy — including when the answer is no.