A game client computes currency balances locally and reports totals to your server — how do you threat-model it?

## The situation A free-to-play game ships a client that tracks a player's in-game currency and cosmetic entitlements locally, then posts totals to the server, which stores them. The design is fast and cheap. It is also unenforceable, and the way to show that in an interview is to model it rather than to assert it. ## Where the boundary goes On a data-flow diagram, the game client is a process running in a trust zone you do not control. The player owns the hardware and the operating system on it. They can attach a debugger, patch the binary, intercept and edit the request before it leaves, or skip the client entirely and speak to your API directly. So the trust boundary is drawn at your service's network edge, and every flow crossing inward is attacker-controlled input — including flows your own code emitted. The boundary faces one way that people often get backwards. It does not protect the client from you; it protects your service from the client. Nothing you place on the far side of it — a check, a constant, a secret, a validation rule — is protected by being there. ## The attacker position that gets missed Most threat models default to an anonymous outsider trying to steal customer data. Here the attacker is the legitimate, authenticated, possibly paying customer, and the asset is money and the integrity of the game economy. That single change reorders the whole model: Information Disclosure barely matters (the player is looking at their own data), while Tampering and Elevation of Privilege dominate. A model that never considers the account holder as an adversary will pass review and still miss the actual threat. ## "Client-side check as UX, not control" The same check often exists twice, for two different reasons, and confusing them is the classic defect: - **On the client:** immediate feedback, responsiveness while offline or on a bad connection, fewer round trips, less server load. Removing it makes the product worse. - **On the server:** the control. Removing it removes the security property. The test is simple: if an attacker deletes or edits the client-side check, what still stops them? If the answer is "nothing", the check was never a control. Grey-out buttons, disabled menu items, hidden admin screens and locally computed prices all fall into this category. ## STRIDE reading - **Tampering** — the reported total is modified in transit or at source; violates integrity. - **Elevation of Privilege** — the modified total grants entitlements the player is not authorized to hold; violates authorization. - **Spoofing** — relevant only if the client asserts *who* it is rather than proving it; violates authentication. - **Repudiation** — a secondary but real consequence: with no server-side derivation, you cannot later distinguish earned balances from injected ones, so you cannot clean up after an incident. ## What the redesign looks like Move the decision, not just the validation. Reduce the API from "set my balance to N" to individually authorizable verbs — "open this chest", "finish this match" — that the server evaluates against its own record of what the player has done. The server owns the economy rules; the client owns the presentation of them. Where full re-derivation is genuinely too expensive, degrade deliberately rather than silently: - enforce invariants (currency is conserved; entitlements only appear via a grant path), - bound rates per account and per action, - detect implausible trajectories and reconcile, - and put the strongest check at the choke point where in-game value converts into something irreversible — a cash-out, a trade, a real-money purchase. ## Where client hardening fits Obfuscation, integrity self-checks and anti-debug measures do have a place: they raise the cost of building the first exploit and slow the packaged tooling that lets thousands of casual users copy it. Model them honestly as **delay**, not prevention — a control that buys time, whose value is realised only if something is watching during that time. They never change who controls the device. An answer that offers client hardening as the primary mitigation is the failure mode interviewers are listening for. ## What you write down A finished model for this design records: the boundary and which side the client sits on; the attacker position (the account holder); the assets (revenue, economy integrity); the threats by category; where each control is enforced; and the residual risk you are consciously accepting, because some fraud always survives and the point of the model is to bound it, not to claim zero.