When threat-modeling a multi-tenant API, where does the trust boundary sit and which STRIDE categories dominate?

## What you are actually being handed A multi-tenant API service is one deployed process (or fleet) that serves many customer organizations out of shared infrastructure. Every request arrives with some credential, and behind the service sits data that belongs to a specific customer. The interview exercise is to draw that system and say what could go wrong. ## The naive drawing, and why it fails Most candidates draw one box for the internet, one box for the API, one cylinder for the data, and one dashed line between the internet and the API. That dashed line is a real trust boundary — it is where an unauthenticated stranger becomes an authenticated caller — but it is the *authentication* boundary, and authentication is not isolation. Once the caller is inside, every tenant's data is on the same side of that line. Nothing about crossing it says which rows this caller may touch. ## Where the decisive boundary really sits In a multi-tenant API the boundary that decides the threat model is **redrawn at every endpoint**. Each handler is a place where an authenticated caller's tenant claim meets tenant-owned data, and each handler either scopes the query to the caller's tenant or it does not. That makes the per-endpoint authorization check the unit of analysis: the model is not "is there a boundary?" but "how many crossings are there, and which ones are guarded?" Concretely, take a business-to-business payroll and benefits API. It exposes employee lookups, payslip downloads, benefit-election writes and a `/reports` endpoint that takes an `employer_id` parameter. The DFD looks like this in plain text: [HR admin of Employer A] --(credential + request)--> || edge || --> [Payroll API] [Payroll API] --(query)--> ( employee + payroll store, all employers ) The `||` marks the authentication crossing. But the interesting annotation is on the *second* arrow, repeated once per endpoint: for this handler, what scopes the query, and where does the scoping value come from? On three query paths that reach the payroll store, two derive the employer from the verified credential and one takes it from the `employer_id` parameter. That third path is the finding, and you can point at it on the diagram. ## Which STRIDE categories dominate, and why STRIDE names six threat categories, each the violation of one security property: | Category | Property violated | In a multi-tenant API | |---|---|---| | Spoofing | Authentication | Concentrated at the edge crossing and at internal hops that trust a header | | Tampering | Integrity | Cross-tenant *writes*: editing another employer's benefit elections | | Repudiation | Non-repudiation | One admin acts for a whole organization; weak attribution hurts disputes | | Information disclosure | Confidentiality | Cross-tenant *reads*: another employer's employee personal data | | Denial of service | Availability | A noisy tenant degrading shared capacity | | Elevation of privilege | Authorization | Acting with another tenant's authority, or beyond your role inside your own | Information disclosure and elevation of privilege dominate, because the shared datastore means a single unscoped query is a breach of another paying customer rather than a bug. Tampering follows them for the same reason on the write side. Spoofing and denial of service are real but sit mostly at the edge; repudiation matters more than people expect when one credential represents an entire organization. That ranking is the point of the exercise. A model that lists all six letters with equal weight for every endpoint has enumerated without prioritizing, and an interviewer reads it as mechanical. ## The annotation that turns a diagram into findings For each endpoint, record three things: 1. **Reachable resource** — which tenant-owned data can this handler read or write at all? 2. **Source of the tenant identity** — a verified credential, or a value the caller supplied? 3. **Where the check happens** — in this handler, in shared middleware, or nowhere? Any endpoint whose tenant identity comes from caller-supplied data, and any endpoint with no entry in column three, is a threat you can state precisely: "an authenticated HR admin at Employer A can read Employer B's employee records through `/reports`." That is a threat, not a vulnerability and not a risk — the vulnerability is the missing filter on that specific path, and the risk is the rated consequence of another employer's personal data being exposed to a customer. ## Two traps worth naming out loud **Unguessable identifiers are not a boundary.** If the model's answer to a missing check is "the ids are random", the threat has been obscured, not removed: identifiers leak through exports, support tickets, integrations and referrals, and the check is still absent when one does. **Enforcement in shared middleware moves the check but not the boundary.** It is a much better design, and it shrinks the number of places to get right, but the model now has to enumerate what bypasses it: endpoints on an exemption list, background code paths that never pass through the request pipeline, and direct datastore access from tooling. The crossings still exist; you have just made them all run through one gate, and the gate's exceptions become the interesting part. ## What a strong answer sounds like "The perimeter is where authentication happens; the boundary that decides my threats repeats at every endpoint where a tenant claim meets shared data. I would list the endpoints, annotate each with what it can reach and what scopes it, and expect information disclosure and elevation of privilege to dominate — with the writes rated alongside the reads."