# 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:

1. **identity paths**;
2. **data sensitivity**;
3. **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](/architecture-api-crypto-and-identity/index/api-authentication-and-authorization.md)
* [Business Logic Abuse and Product Abuse](/application-security-and-secure-sdlc/index-3.md)
* [Secure Architecture Patterns](/architecture-api-crypto-and-identity/index-1.md)

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/application-security-and-secure-sdlc/index/multi-tenant-and-microservice-threat-modeling.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.