🧩 Tenant Isolation, Object-Level, and Workflow Abuse
Intro: A product can pass many traditional security checks and still fail badly at tenant isolation or workflow authorization. This page focuses on the authorization and workflow mistakes that look small in code but large in production.
What this page includes
- object-level access failures
- workflow state abuse
- how to test and monitor for cross-tenant risk
- authorization patterns that survive real product complexity
Typical failure modes
- object IDs predictable enough to enumerate;
- checks at the route level but not the object level;
- workflow state changes that skip authorization on background processing;
- support or admin tooling bypassing the same checks as customer paths.
Better patterns
- authorize every sensitive object operation server-side using resolved tenant and actor context;
- re-check authorization on asynchronous continuation steps;
- separate “can see this object exists” from “can read or mutate this object”;
- log requested object, resolved object owner, tenant context, and decision result.
Monitoring ideas
- many forbidden or not-found responses across many object IDs;
- high-volume lookups across many tenants or orgs by one actor;
- export jobs or search queries with fan-out above the normal workflow;
- admin or support actions that touch many unrelated tenants quickly.
Related pages
Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.