Engineering · July 6, 2026

Server-Side Leaderboard Validation: Catching Cheated Scores Without Punishing Legit Players

A leaderboard that trusts whatever number the client sends is a leaderboard that will have a suspiciously round nine-digit top score within days of launch, submitted by someone who never actually played that run.

Published July 6, 2026

The single most important rule is that the client is never trusted with the authoritative score. A network request that simply POSTs a final integer to a leaderboard endpoint is trivially editable with any network inspection tool a player already has installed, and it will be edited the moment a leaderboard has any social currency attached to it at all — which, for a shmup community that cares about score-attack play, is almost immediately. The server needs enough information to independently verify a score is plausible, not just record whatever value arrives.

Replay-based validation is the strongest approach and the most expensive to build

The most robust method is to require the client to submit the recorded input stream for the run — the same deterministic replay data described in save and replay systems for deterministic playback — and have the server (or a sandboxed instance of the game's simulation running headless) recompute the score from those inputs rather than trusting the submitted number at all. This closes almost every cheating vector short of tampering with the simulation itself, but it requires the game's simulation to be fully deterministic and replayable outside the normal client, which is a real engineering investment that needs to be planned for from early in development rather than bolted on right before a leaderboard ships.

Cheaper heuristic checks catch the common cases

For a small team that can't justify building full server-side replay verification, a layer of plausibility checks catches the majority of casual cheating attempts without nearly as much infrastructure. Score-per-second caps derived from the theoretical maximum scoring rate of the game's own systems reject anything mathematically impossible outright. Run-duration checks that compare submitted playtime against the minimum time the levels involved could possibly take to clear catch submissions claiming a full clear in an implausibly short window. None of these heuristics catch a sophisticated cheater willing to craft a submission that stays just inside plausible bounds, but they're cheap to implement and they stop the low-effort tampering that would otherwise be the first thing anyone tries.

Regional and per-mode leaderboards multiply the validation surface

A single global leaderboard is the simplest case to validate, but many shmups split scores across difficulty tiers, ship loadouts, or regional boards, and each split multiplies the number of plausibility rules that need to exist — a score that's entirely reasonable on the hardest difficulty tier might be mathematically impossible on the easiest one, so a single shared validation rule across all boards either under-catches on the hard tier or over-flags on the easy one. Building validation rules per category from the start, rather than one generic rule applied everywhere, avoids a painful retrofit once a game has multiple difficulty tiers or loadout-specific boards each with genuinely different achievable score ranges.

Rate limiting and account requirements reduce the attack surface

Requiring a real account (rather than an anonymous device ID that can be reset at will) before a score can be submitted, combined with a reasonable rate limit on submission frequency, doesn't stop a determined cheater but meaningfully raises the cost of mass-submitting fake scores to flood a leaderboard. The Valve Steamworks leaderboard documentation is a useful reference here even for a team not shipping on Steam, since its discussion of trusted versus untrusted score writes reflects lessons learned across a huge number of shipped games with the exact same tampering problem.

Be transparent about what gets flagged and why

A leaderboard that silently drops or hides suspected cheated scores with no explanation, visible only as an entry that mysteriously disappeared or never showed up, breeds far more suspicion and community friction than one that's upfront about its validation process. Publishing a plain-language explanation of what the automated checks look for — without necessarily revealing exact thresholds a cheater could game — and providing a clear appeal path for a player whose legitimate score got flagged does more for community trust than a purely opaque system ever could. Communities around competitive shmups tend to be small and tightly connected, and a reputation for capricious or unexplained leaderboard moderation spreads fast within that kind of community, doing lasting damage to a game's competitive scene well beyond the specific disputed score.

False positives cost more trust than false negatives

An aggressive validation system that occasionally flags and hides a legitimate exceptional run — a genuinely skilled player who happens to be an outlier — does more damage to community trust than letting a handful of cheated scores slip through undetected, because the legitimate player who got flagged will say so publicly and loudly, and other players will believe them. Building a manual review queue for scores that fail automated checks, rather than auto-rejecting silently, gives a path for genuine outlier runs to get reinstated once a human confirms them, and it keeps the automated system from becoming the sole arbiter of what's a legitimate world-class run.