Multi-tenant data isolation

The tenant/organization id is read from the authenticated session or a verified token, and from nowhere else. Taking it from the request body, the query string, a path parameter or a client-supplied header is rejected, even when the code also checks membership afterwards. Any tenant id the client can send is a tenant id the client can change.

Blocks: this is the root of the entire isolation model — one exception voids all the others.

Every select, update and delete against a tenant-scoped table includes the tenant predicate — including lookups by primary key. "The id is a UUID so it's unguessable" is not an authorization check: ids leak through exports, logs, support tickets and shared URLs.

Blocks: a single missing predicate is a cross-customer data leak.

Any cache key derived from an entity id, a user input, or a computed result includes the tenant id. A key without it serves one customer's data to another, and the poisoned entry outlives the deploy that introduced the bug — so the fix does not fix it.

Blocks: cache leaks are cross-customer, persistent, and invisible in logs.

Uploads and generated files are written under a tenant-scoped prefix, and any signed URL is minted with a short expiry (15 minutes or less). A flat bucket namespace means a guessable or enumerable key is a direct read of another customer's document, with no application code involved.

Blocks: object storage bypasses every check that lives in your application.

A queued job or scheduled task includes the tenant id in its payload, and the handler re-establishes the scope from it before touching data. Relying on ambient or thread-local context inside a worker is rejected — the context that produced the job is long gone by the time it runs.

Blocks: a worker with the wrong scope writes to the wrong customer, silently.

A new table holding customer data declares a non-null tenant column with a foreign key to the tenant table, and an index leading with that column. Adding it later means a migration on a populated table plus an audit of every query written in the meantime.

Blocks: the cost of getting this wrong grows every day the table exists.

Before creating an invitation or changing a role, verify that the actor is a member of the session's tenant with permission to grant, and that the target user and target role belong to that same tenant. Cross-tenant privilege escalation is the highest-severity bug this product category has, and the code path looks entirely ordinary.

Blocks: it grants an attacker durable, legitimate-looking access to another customer.

A query that intentionally spans tenants — admin tooling, billing rollups, internal analytics — goes through a named unscoped helper and logs the actor who ran it. Without a marked escape hatch, people quietly drop the filter in ordinary code and the two cases become indistinguishable in review.

Warns: legitimate uses exist, so the goal is visibility — the reviewer confirms the escape hatch was intended.

A resource belonging to another tenant returns exactly what a nonexistent resource returns. A 403 confirms the id exists, which turns any endpoint into an enumeration oracle for another customer's data volume, naming scheme and activity.

Warns: it leaks metadata rather than content, but it is what makes targeted attacks cheap.

Every new tenant-scoped endpoint ships a test asserting that a member of tenant B receives a 404 on tenant A's resource. Isolation is the property manual testing never exercises, because a human is only ever logged into one account at a time.

Warns: missing tests do not break production today — they just guarantee nobody notices when it does.