multi-tenant isolation is a security boundary, not a query filter

Mon, 06 Apr 2026 00:00:00 +0000

i’m building a small multi-tenant cms for local businesses — a barbershop, a physio, a bakery each get a little site they can edit themselves. one payload backend, one postgres, many tenants. the whole promise is that the bakery’s editor logs in and sees the bakery. not the barbershop. never the barbershop.

so during a pre-launch hardening pass i did the thing i’ve learned to do: i stopped admiring the isolation and started attacking it. i logged in as a low-privilege editor — scoped to exactly one tenant — and sent one request to edit my own user account. not someone else’s. mine. i just added a second tenant to the list of tenants i belong to.

it went through. 200. and on the next request i could read, edit and delete another business’s pages as if they were my own.

nobody broke in. i handed myself the keys through the front door, using an endpoint that exists specifically so users can edit themselves. an isolation boundary you can widen with a PATCH to your own profile isn’t a boundary. it’s a default you forgot to close.

multi-tenancy on krtffl.dev

multi-tenant isolation is a security boundary, not a query filter