🏢 Multi-Tenant and Microservice Threat Modeling
Intro: The most expensive Product Security incidents are rarely just “input validation” bugs. They are tenant-boundary failures, control-plane leaks, service identity mistakes, and asynchronous workflow abuse.
What this page includes
- a practical review model for SaaS products and service meshes
- top trust boundaries to document first
- common attack chains that combine app, API, and cloud paths
- questions that reveal architecture weaknesses early
The four trust boundaries that matter first
1. tenant plane versus tenant plane
Can one tenant's object, export, search result, webhook, or background job touch another tenant's data?
2. tenant plane versus admin plane
Can support tooling, back-office jobs, or internal dashboards bypass normal safety checks? Admin planes deserve their own threat model because they often have broader search and mutation powers than the product itself.
3. service plane versus cloud plane
Can a service identity read secrets, assume roles, publish images, or change deployment state? This is where application compromise becomes infrastructure compromise.
4. release plane versus runtime plane
Can CI/CD change what runs without enough human or policy friction? If yes, the build system is part of the product's threat model.
Microservice review checklist
For each service, document:
- inbound identities it trusts;
- outbound calls it makes;
- data stores it can reach;
- secrets or tokens it can read;
- authorization decisions it makes locally versus centrally;
- telemetry fields required to reconstruct abuse.
High-value abuse cases
- object-level authorization bypass through IDOR-style enumeration;
- bulk export or background job abuse that bypasses per-request checks;
- webhook replay or forged callback states;
- service account abuse to read secrets or message queues;
- event poisoning in asynchronous workflows;
- internal API trust based only on source network or gateway headers.
Decision points to force early
| Topic | Weak default | Stronger default |
|---|---|---|
| tenant identity | tenant ID from client only | tenant context bound server-side and revalidated per object |
| service trust | implicit trust behind the gateway | service-to-service auth plus resource-level authorization |
| admin actions | same flows, more privileges | separate admin plane, tighter logging, just-in-time access |
| async events | queue access equals authority | event signing, schema validation, consumer authorization |
Output pattern
A useful artifact is a one-page map with three overlays:
- identity paths;
- data sensitivity;
- privileged operations.
That gives reviewers a way to see where a low-privilege feature unexpectedly touches a high-privilege service or dataset.
Related pages
- API Authentication and Authorization
- Business Logic Abuse and Product Abuse
- Secure Architecture Patterns
Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.