A leaderboard is only as honest as the score submission behind it. If the client sends a number and the server stores it, anyone can post any score. Validate on the server, check plausibility, keep replay evidence when you can, and label rankings you cannot verify.
The weak design
The classic mistake is an endpoint that accepts player id and score. Signing the request inside the client does not fix it, because the signing key ships with the game and attackers can extract it. Obfuscation raises effort a little, nothing more.
Stronger designs, in order of strength
- Server simulated results. The server runs or recomputes the match, so the client cannot invent an outcome. Best, and costly for some genres.
- Replay verification. The client submits the input log, and a server or worker re-runs it deterministically to confirm the score. It needs a deterministic game loop.
- Session tokens from the server. The server issues a signed token when a run starts, with a time and seed. The score must come back with that token, within a plausible duration.
- Plausibility checks. Reject scores that exceed what the level allows, that arrive faster than the minimum possible run time, or that jump far beyond the player's history.
Combine them. A token without plausibility checks still lets an attacker post the maximum.
Rate limits and identity
Cap submissions per account and per run token. Tie scores to accounts with a real sign in, not a client generated id, otherwise one person can create thousands of identities. Watch for brand new accounts that land at the top of a board.
Tiered boards
Not every game can verify everything. Say so honestly:
- A verified board for scores that passed server or replay checks.
- An unverified or casual board for the rest.
- A review queue for the top ranks before prizes or badges are awarded.
If prizes are involved, hold payouts until the top entries are reviewed.
Handling a poisoned board
Keep the raw submission data so you can find and remove bad entries in bulk. Allow removal without deleting the player's account, since some cases are bugs and not cheats. Record why each entry was removed, and publish a short rule on how scores are checked.
Review checklist
- Does the server issue the run start, or does the client announce it?
- Is any key or secret used for signing shipped inside the client?
- Can the same token submit twice?
- Are impossible values rejected and logged?
- Can you re-verify old scores after you fix a bug?
Safeguard can scan the dependencies and APIs behind your score service. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Does signing the score in the client stop fake scores?
No. The signing secret is inside the client, so it can be extracted and reused.
What if my game cannot be replayed?
Use server issued run tokens, plausibility checks, and a separate unverified board.
Last reviewed: 19 October 2026.
