The challenge
Translate a distrust-the-client architecture into a large enough implementation that every authentication, session, scoring, economy, administration, and persistence path preserves the same authority rules.
.NET Game ServerResearch prototype
Game Server deep dive
From Trust Model to Implementation
The server began with a simple security assumption: a player-controlled client can establish identity and make requests, but it cannot be trusted to decide authoritative competitive state.
The project
Before implementation, the system was decomposed by authority. User data, scores, leaderboards, session logs, administrator records, and enforcement state were intended to have different read and mutation boundaries. Clients would never directly write authoritative storage; they would submit requests and the server would decide whether and how state changed.
Competitive integrity followed from that model. An online game session would receive a unique identity and produce periodic server-side evidence about game state. Score submission was intended to be checked against the history of that session rather than accepted simply because an authenticated client claimed a number. Offline play remained available, but offline-generated competitive state was intentionally prevented from later becoming trusted online state.
The architecture then became a real ASP.NET Core system. The implementation added SQL Server and Entity Framework persistence, JWT and refresh-token authentication, WebSocket sessions, modular game handlers, server-maintained scoring, object lifecycle records, positional history, leaderboards, player progression, cosmetics, and gameplay telemetry.
Implementation also demonstrated why a good threat model does not automatically produce secure software. A later adversarial review reproduced code paths that violated the project's own architectural assumptions: caller-supplied identity could cross account boundaries, ordinary players could reach administrative database functionality, stale credentials retained powers they should not have had, and multiple scoring/session paths could award illegitimate state.
That failure is part of the project rather than something hidden from the case study. The architecture provided a useful standard precisely because it made the implementation defects legible: several failures could be described as places where code accidentally allowed the client to become an authority again. The resulting security baseline and audit findings define what would need to change before the prototype could be considered for public exposure.
The approach
Use the original threat model as an invariant rather than a design artifact that becomes irrelevant after coding starts. Implementation creates concrete enforcement mechanisms; adversarial testing then checks whether those mechanisms preserve the intended boundary across every path that can mutate authoritative state.
What matters
Built around the use case.
Authority before API design
The system was first divided according to who could read, request, approve, and mutate each class of information.
Evidence-based competition
Session telemetry, object histories, positional information, and server-maintained score state were explored as evidence for validating competitive claims rather than trusting submitted scores.
Failure as architecture feedback
The later audit exposed concrete cases where implementation violated the intended model, turning security defects into actionable information about where architectural invariants had not survived coding.