A game client runs on hardware the player controls, so a determined player can read, change or replace it. The safe design is server authority: the client sends what the player wants to do, and the server decides what happens. Anything the server accepts as fact from the client becomes something someone will fake.
What "the client is hostile" means in practice
You do not need to assume every player is an attacker. You need to assume that some will be, and that tools to tamper with clients get shared quickly. Memory editors, modified binaries, proxies that rewrite traffic and scripted bots all exist because the client is within reach.
The OWASP Mobile Application Security Verification Standard separates its resilience controls, such as integrity checks and obfuscation, from the rest of its requirements. That split is a useful reminder that tamper resistance raises effort but is not a trust boundary. Your server is the boundary.
Decisions that belong on the server
- Currency, inventory and entitlements. The client may display them, but never decides them.
- Match results and scores. Accept inputs and recompute outcomes, or validate reported results against what is plausible.
- Cooldowns, damage, speed and other limits. Check them against server state, not a client claim.
- Purchases. Verify receipts on the server before granting anything.
- Progression gates, such as unlocking a level or a creator tool tier.
Validate input shape and plausibility
A server that does authority work still needs to check each request. Is this action allowed in the current state? Is the number within range? Could the player physically have done this in the time since the last message? Reject and log what fails, since repeated implausible input is a useful signal.
Rate limit by account for each action type, not just overall. A client that sends fifty fire commands in a frame is telling you something.
Be careful with trust you cannot avoid
Latency pushes games toward client side prediction, where the client shows an outcome before the server confirms it. That is fine for feel. The server's answer must still win, and the client should correct itself when it disagrees.
Some genres, like single player games with leaderboards, cannot fully verify results. Be honest about it. Separate trusted and untrusted leaderboards, or verify with replays.
Secrets do not belong in the client
Embedded API keys, signing keys and admin endpoints in a shipped build are public, whatever obfuscation you add. Keep privileged keys server side, and give the client short lived, narrowly scoped tokens instead.
A review checklist
- List every value the client sends. Mark which ones the server uses as truth.
- For each, ask what happens if the value is wrong, huge, negative or repeated.
- Move every economy and progression decision server side.
- Search the build for embedded secrets and internal URLs.
- Add logging for rejected inputs and review it after each release.
Safeguard can help with the dependency side of this work: SBOM and dependency scanning for your backend services. You can start with the free scan at https://gold.safeguard.sh/scan.
Quick check
Does obfuscating the client solve cheating?
No. It raises effort for attackers, but the server must still validate everything the client sends.
Is client side prediction a security problem?
Not by itself. It becomes one if the server accepts the client's predicted outcome instead of computing its own.
Sources
Last reviewed: 19 October 2026.
