Draw the trust boundary first
List the clients, identity provider, game server, services, build workers, and media hosts. Draw the flows between them and mark the actions that change data or cost money. Trust boundaries often appear where a public client talks to an authenticated service or where a build job receives deployment credentials.
Ask what an attacker could do with a copied request or a leaked token. Running the same request twice and using a valid account to reach another account’s data are useful cases that should be tested before launch.
Treat a client as an untrusted participant
A player’s device can show responsive movement immediately. It still should not decide who owns a reward, the final result of a trade, or whether a shot was valid. Check identity, possession, range, and state on the authority responsible for that feature. For a retryable mutation, track idempotency and define how a duplicate resolves.
Reduce access around builds and media
Use distinct credentials for publishing, storage administration, and read-only access. Keep private assets behind the correct application authorization when issuing manifests, media segments, and download links. Think through caches: a response that was valid for one session can be sensitive if a shared cache serves it to another.
Practice recovery
Know how to revoke a token, identify the build that introduced a regression, and roll traffic back without losing player data. Keep a record of which people and systems can publish. Review incoming dependencies and verify that someone owns vulnerability reports when the website or game is public.