Your Public Leaderboard Will Get Cheated: The Trust Problem and the Server-Side Fix (2026)

There is a recurring genre of indie-dev post that goes roughly: "I added a global leaderboard, players loved it, and three days later the top ten are all impossible scores and my real players are demoralized." Sometimes it is a blatant 2-billion-point entry. Sometimes it is subtler - a speedrun board topped by a time no human route can hit, or a score reached with an "unintended strategy" that is technically an exploit. Either way the reaction is the same: was the leaderboard a mistake?

It is worth sitting with how small a game has to be for this to happen. One developer posted that they had woken up to three cheaters holding 616 credits in a game that grants about 10 per round - a total no amount of legitimate play produces - and added, almost apologetically, that their game "barely has a couple hundred players" and was "not even in a demo state". They assumed the players had modified the build files. A commenter corrected them: it "took like 10 secs with cheat engine". That is the real timeline. Not a popular game, not a determined attacker, not a sophisticated exploit - a couple of hundred players and ten seconds of effort. The most useful reply in that thread was also the shortest: "you probably just need to add some validation in your server layer - never trust the client."

It was not a mistake to want one. Leaderboards are one of the cheapest retention features you can ship - competition, bragging rights, a reason to play one more run. The mistake is a specific, fixable architectural decision: letting the client tell the server what the score was. Fix that and the leaderboard goes back to being an asset.

Why "the client sends the score" always breaks

The default way a leaderboard gets built is the way that breaks. The game finishes a run, computes a score locally, and POSTs it to a leaderboard endpoint. The endpoint stores it. That is the whole design, and it is indefensible, because everything between the player and your endpoint is inspectable and replayable:

• The request is visible. Anyone can open the network tab, watch the score submission, and replay it with a different number. No game modification required - just a copied cURL command with score=999999999.
• The client is modifiable. Memory editors, decompiled builds, and simple proxies let a determined player change the score before it is sent. For a web game it is trivial; for a native game it is a weekend.
• "Unintended strategy" is not even cheating. Some of your top entries will come from players who found a legal-but-degenerate route your scoring did not anticipate. They did not hack anything. Your score function rewarded something you did not mean to reward, and now it is on the board forever.

The through-line: if the number the server stores is a number the client chose, your leaderboard measures "who is most willing to cheat", not "who is best". That is the trust problem, and no amount of obfuscation, HTTPS, or API keys fixes it, because the cheater is a legitimately authenticated client sending a legitimately-formatted request with a dishonest value.

You are already exploited. Now what?

Most people read this after the board is already full of garbage. There are three honest moves, and picking is a product decision, not just a technical one:

1. Purge the impossible entries. Fast, satisfying, and temporary. Delete anything above a hard ceiling your game cannot produce. It cleans the board for a day and does nothing to stop the next submission - but it buys time and signals to real players that you are watching. The community question "should I delete high scores made with exploits?" almost always resolves to yes, with a public note, because leaving them poisons the board's credibility.
2. Segment verified from unverified. Keep the open board as a "fun / unverified" list and add a separate "verified" board that only accepts server-validated scores. This is the pragmatic middle path: you do not have to gate everyone on day one, and your competitive players get a board they can trust. Speedrun communities live on exactly this split.
3. Validate server-side and reset. The real fix. Move score authority to the server (below), wipe the board, and relaunch it as trustworthy. You lose the old numbers, but they were fiction anyway. Announce it as a fresh season and you turn the reset into an event instead of an apology.

The server-side fix: the server owns the score

A trustworthy leaderboard follows the same principle as any authoritative game server: the client proposes, the server disposes. There is a spectrum of how much you validate, and you pick the point that matches your stakes:

• Server-computed scores (strongest). The server witnesses the gameplay - it runs or validates the session - so the score is something it calculated, not something it received. A submitted number is ignored entirely. This is natural when the match already runs on an authoritative backend, and it is the only approach that is genuinely un-fakeable.
• Replay / event validation (strong, cheaper). The client submits the score plus the sequence of inputs or events that produced it. The server re-simulates or sanity-checks that the events could produce that score under the real rules, and rejects mismatches. Common for puzzle, arcade, and speedrun games where re-running the input is cheap.
• Bounds and rate sanity checks (weak but non-trivial). The server enforces a maximum possible score, a minimum plausible session length, a rate limit per account, and rejects statistical impossibilities. It will not stop a careful cheater who stays inside the bounds, but it filters the lazy 999,999,999 submissions that make up most of the problem.

The other half of a real leaderboard is the boring plumbing people underestimate: authenticated accounts so a ban means something (a purely anonymous board can be re-spammed forever), atomic writes so ties and concurrent submissions do not corrupt ranks, and time-windowing for daily, weekly, and seasonal boards - which is its own headache of timezones, resets, and keeping history. This is exactly why devs post "my daily leaderboard just broke, is there a tool for this?" - the windowing and reset logic is deceptively fiddly on top of the validation. The mechanics of ranked queries like top-N and around-me are covered in our leaderboard kata.

Where anti-cheat ends and leaderboards begin

A leaderboard is a focused instance of the broader server-authoritative anti-cheat problem, and it is worth being precise about the boundary. General anti-cheat asks "is this player's live behavior legitimate?" - aimbots, wallhacks, speed. Leaderboard integrity asks a narrower, more tractable question: "could this specific score have been produced by legal play?" You do not need a kernel anti-cheat team to answer the second one. You need the server to hold the scoring rules and check submissions against them. That is achievable for a solo dev in a way that full behavioral anti-cheat is not, which is the good news buried in every "my leaderboard got cheated" post: this particular problem has a clean, affordable fix.

FAQ

Can I just obfuscate or encrypt the score submission?
No. Obfuscation raises the effort slightly and stops nobody who wants in - the client still has to produce a valid submission, so a determined player extracts the format and forges it. Encryption in transit (HTTPS) stops eavesdroppers, not the authenticated client who is themselves the cheater. The only fix is the server not trusting the submitted number.

Do I have to run an authoritative server just for a leaderboard?
Not necessarily. If your game is single-player or casual, replay/event validation gets you most of the way without a live authoritative match server - the client submits the inputs, the server re-checks them. You only need a full authoritative match server when the gameplay itself is multiplayer and already needs one.

Should I delete cheated scores or leave them?
Delete the impossible ones, and say so publicly. Leaving obvious cheats on the board tells your honest players that the board is meaningless and that you are not watching - which is the exact retention damage the leaderboard was supposed to prevent. If you cannot yet validate, segment into verified and unverified rather than leaving one poisoned list.

Where Crux fits

Crux is a managed game backend with leaderboards as a first-class, server-authoritative primitive - authenticated identity so bans stick, server-side score validation so a submission is a claim to check rather than a fact to store, atomic ranked writes, and built-in daily, weekly, and seasonal windows so you are not hand-rolling reset logic. Instead of building the submission path, the validation, the tie handling, and the time-window plumbing yourself - and then rebuilding it after it gets exploited - you define what a valid score is and Crux owns the rest. It pairs with server-authoritative validation for the broader anti-cheat surface. See the full picture in the Crux overview, or start with what an authoritative game server actually is.

The one-line version: a public leaderboard is not a mistake, but a client-authored score is. Move the score to the server and the board becomes an asset again.