One API service exposes public, partner and internal tiers — how do you threat-model it and where do you invest?

## One deployment, three different attackers A single service often speaks to populations that have nothing in common. Take a freight-brokerage platform: one service exposes a **public** rate-quote endpoint that anyone on the internet can call, a **partner** booking API that carrier integrators call machine-to-machine with issued client certificates, and **internal** operations endpoints that the ops team's tooling uses — reachable on the same host and the same listener as the other two. Because it is one codebase and one deployment, it gets drawn as one box with one boundary. That drawing hides the whole question. The right model gives each tier its own external entity, its own crossing, and its own row in the analysis, because the three differ on everything that decides a threat: who can reach it, what proves who they are, what operations it unlocks, and what happens when its credential leaks. | Tier | Attacker population | Credential shape | Dominant threats | Asset at stake | |---|---|---|---|---| | Public | Anyone on the internet, unauthenticated | None, or an unauthenticated key | Denial of service, probing for reachable non-public routes, scraping | Availability and pricing information | | Partner | A compromised or malicious integrator's service account | Long-lived machine credential, e.g. an issued client certificate | Spoofing at the edge, then tampering with bookings and rates; weak repudiation | Money and transaction integrity | | Internal | An authenticated tenant who guesses or finds the route | Whatever the other tiers use, since it is the same listener | Elevation of privilege, cross-customer information disclosure | Cross-customer data and trade-secret metrics | ## What changes when the client is a machine The partner tier is where senior candidates earn the question, because machine-to-machine identity behaves differently from a human session in ways a threat model must record: - **The credential is at rest somewhere.** It lives in a config file, an image, a CI variable or an operator's laptop, so its exposure paths are deployment paths, not phishing paths. - **It effectively never expires.** Rotation requires a coordinated change with an outside company, so in practice it is long-lived. Model the *actual* rotation cadence, not the policy. - **Its scope is the whole partner.** There is no per-user narrowing, so theft yields everything the integration can do, immediately. - **No human is behind it.** There is nobody to notice a strange login, no interactive step-up to interpose on a sensitive action, and no session that ends when someone closes a laptop. - **Attribution collapses.** Many humans at the partner act behind one account, so the audit trail answers "which partner" and not "which person" — a repudiation problem when a disputed booking or a manipulated rate has to be reconstructed. Note what the certificate does and does not establish: it identifies *which partner is calling*. It says nothing about which operations that partner may perform or which loads they may touch — those are still per-endpoint authorization decisions on the other side of the crossing. ## Why the internal tier is usually the finding Internal endpoints that share a listener with authenticated tiers are reachable by every authenticated caller. "Undocumented" narrows discovery; it is not an authorization decision, and routes surface through error messages, client bundles, path guessing and ordinary curiosity. The sharpest version of this appears in a product-analytics platform whose cross-customer benchmarking endpoints — built for the company's own dashboards, never listed in the public API reference — return aggregated funnel and revenue metrics across all customers. A rival company that is also a paying tenant authenticates normally, calls the unlisted route, and reads competitors' trade-secret metrics. Nothing was breached in the usual sense; the tier was never modeled as a surface, so nobody asked what proved the caller was allowed to be on it. ## Where to invest, and how to defend the choice Three levers, in rough order of return: 1. **Give the internal tier a different reachability**, not just a different check: its own listener, network path and identity domain. This is the only change that survives a future authorization bug in the shared pipeline, and it is the one worth spending a real budget on. 2. **Enforce per-endpoint authorization uniformly on what remains**, with the tier recorded as an explicit property of every route so that "which surface is this on?" is answerable from the code rather than from folklore. 3. **Make partner credentials operable**: a rotation path you have exercised, per-actor context that the partner passes and you log, and monitoring of the partner's behaviour envelope, since no human will report the anomaly for you. Defend the ranking with blast radius and detectability rather than threat counts. The public tier has many attackers and little to steal; the partner tier has few attackers and direct access to money, with the slowest detection; the internal tier has a large authenticated population and material that was never meant to be cross-customer. That is a prioritization argument an architecture review can act on, and it is what "threat-model this" is really asking for. ## The failure to avoid Do not answer with one boundary because it is one process. Deployment topology is a fact about convenience; the attacker population is a fact about exposure, and the model follows the attackers.