Discussion on "Enforcing Multi-Tenant Isolation Structurally, Not by Convention"

Nazmul Khalid · 2026-10-16T13:24:05.275Z

Originally published at nazmulkhalid.com. TL;DR: Relying on every query to remember WHERE schoolId = ... doesn't survive a real codebase. Bicitra EMS injects the tenant scope automatically with a Pris

The Laravel version of this exact failure is the global scope everyone adds to the tenant models and then quietly bypasses in the admin panel — one withoutGlobalScopes() in an export, one raw DB::select in a report, and the same class of leak opens. The registry idea is the part I'd steal: structural enforcement validated at write time rather than a scope applied at read time. StackShortlist's test suggestion is the missing piece, honestly. Without a failing test on registry drift, the registry becomes a convention with extra steps — and the eighth endpoint is only safe until someone adds the ninth relation by hand.

The nested include gap is a great catch. Putting tenant-scoped foreign keys in one registry and checking them at write time means the eighth endpoint is safe by default. Did you also add a test that fails if a new relation gets added without a registry entry?

Not yet, and that's a fair gap to point at. Right now, adding a tenant-scoped relation means adding it to the registry by hand. The file's header comment says so, but that's still convention. The test I have in mind reads Prisma's schema metadata, finds every foreign key between two tenant-scoped models, and fails if one is missing from the registry. That turns the last manual step into a CI failure.

Search Hashnode

Enforcing Multi-Tenant Isolation Structurally, Not by Convention

Responses(3)