Walk me through applying STRIDE to the boundary where our order service calls the payments service over the network.

Short answer

Apply STRIDE to one named boundary, not the whole system at once. For an order-to-payments call, check caller authentication, request integrity, auditability, sensitive-data leakage, retry-driven denial of service and over-broad payment privileges.

Keep threat modeling explicit in the answer because that is the concept the interviewer is actually trying to test. A good threat modeling explanation names the trade-off, the failure mode, and the evidence you would use before choosing.

Framing the boundary before applying the letters

STRIDE is easy to recite and easy to apply badly, because the temptation is to force all six categories onto a system as a whole rather than onto a specific boundary a request actually crosses. Here the boundary is precise: the order service, having decided a charge should happen, sends a request across the network to the payments service, which acts on money. That precision matters, because STRIDE threats are properties of an interaction, not of a component, and the mitigations differ depending on which side of the boundary is trusted with what.

Spoofing asks whether the payments service can be certain the request really came from the order service and not from something impersonating it. On an internal network this is easy to underestimate, because "internal" quietly becomes a synonym for "trusted" without anyone deciding that. The mitigation is mutual TLS or a signed service-to-service token scoped narrowly to this call, so the payments service authenticates the caller rather than assuming network position implies identity.

Tampering asks whether the request — specifically the amount and the recipient account — could be altered in transit or by an intermediary. TLS in transit addresses the network path; the boundary-specific concern is whether anything between the order service forming the request and the payments service acting on it, such as a caching proxy or a message broker in between, could rewrite the payload without either service noticing. A signed request body, checked at the payments service, closes the gap TLS alone leaves at any hop that terminates and re-originates the connection.

Repudiation asks whether either party can later deny the charge happened, or deny they authorised the specific amount. This matters more here than in most boundaries because money is involved and a dispute is a real, not hypothetical, future event. The mitigation is an immutable, timestamped audit log on both sides recording the exact request and response, with an idempotency key that ties a specific charge attempt to a specific order unambiguously.

The categories that carry the real weight here

Information disclosure asks what leaks if this traffic, or the logs either service writes about it, are read by someone who shouldn't. Card details, even tokenised references, and precise transaction amounts are exactly the kind of payload that should never appear in a log line, an error message returned to a client, or a trace exported to a third-party observability platform by default. This is the category worth spending real attention on for a payments boundary specifically, because the failure is usually not a breach of the network call itself but an accidental leak through infrastructure built for a different purpose — logging, tracing, error reporting — that nobody threat-modelled because it doesn't look like "the boundary."

Denial of service asks what happens if the payments service becomes slow or unreachable, or if the order service floods it. This is where distributed-systems failure reasoning and threat modeling meet: a naive retry loop from the order service during a payments outage is not an external attacker, but it produces exactly the same effect as one, and STRIDE does not care whether the actor is malicious or just badly configured. The mitigation set is the ordinary resilience toolkit — timeouts, backoff with jitter, a circuit breaker — applied because a threat model surfaced the need for it, not because someone read a list of resilience patterns separately.

Elevation of privilege asks whether the order service holds more capability at this boundary than the specific action requires. If the credential the order service uses to call payments can also issue refunds or query arbitrary customers' payment histories, then a compromise of the order service — a dependency vulnerability, a leaked credential, an injection bug — escalates into a payments-level compromise rather than staying contained to "can create charges for orders it owns." The mitigation is scoping the credential narrowly: this specific integration can create a charge tied to an order id it is allowed to reference, and nothing else.

flowchart LR
    O[Order service] -->|mTLS + scoped token| P[Payments service]
    O -.spoofing, tampering.-> P
    P -.info disclosure via logs.-> L[Log and trace pipeline]
    O -.DoS via retry storm.-> P

The arc worth staring at is the dotted one into the log pipeline. It is not the request path anyone drew first, and it is exactly where a payments threat model most often finds an unaddressed leak.

STRIDE against one named boundary produces six specific, checkable answers; STRIDE against "the system" produces six vague ones, and the difference is entirely in picking the boundary first.

© 2026 Preptima. Originally published at preptima.com.