Sending a client-side high-score to a server securely

The server can't fully trust any data it receives from the client, so validating high scores is difficult.

Here are a few options:

  1. Obfuscate the client-side code and traffic to the server. This is the easiest option - it will still be possible to cheat, but probably won't be worth anyone's time.

  2. Send a full or partial replay of the game to the server for validation. The player's moves can be run on the server to determine the legitimate score. This will work for some games and not for others.

  3. Move the game logic and validation to the server. The client simply relays each move to the server, where it is validated and the game state updated.

It comes down to how your game works, how likely it is that people will cheat, and how much you care if they do.


If your attacker were a man-in-the-middle attacker on the network layer, then https would be enough. But unfortunately your attacker is the client, so this is rather pointless.

Rule number one of cheat-proofing games: Never trust the client! The client is in the hands of the enemy.

Javascript games run in the user's web browser. As you as a web developer surely know, every web browser nowadays comes with a build-in debugger which can view and change all variables while an application is running. The user can simply use the debugger to change their score before it is submitted. There is nothing you can do to prevent that. With browser-based games you can't even slap a 3rd party anti-cheat tool on them (which are of dubious value and ethically questionable anyway).

The only countermeasure is to implement all game mechanics worth manipulating on the server. The client should do nothing but forward the user's commands to the server and visualize the gameplay based on the server's messages. The actual gameplay should happen on the server where it is out of reach of the cheaters.

Yes, this means that you will have to redesign your game's software architecture from scratch. It also means you will have to add some prediction and interpolation code to make network lag less visible. And it also means that you will need far better server hardware and a better internet connection for your server(s). But when you want a cheat-free online game, that's the only option.


To achieve secure game high score, what you need is a "proof of work", or rather, more appropriately called proof of play.

A proof of work/play is any data that's hard to compute before finishing the game, but easy to compute once you finished the game and is easy to be verified by the server. For example, for a Sudoku game, a proof of work is the solution to the puzzle.

Unfortunately, there's no generic way to integrate suitable proof of play system in many games. It's not always possible to integrate a proof of play without tweaking or rehauling the game play, or limiting the scope of the leaderboard to just elements where you can include sufficiently secure proof of play.

Proof of play on a game starts by the server issuing the seed for the game's RNG. The client then will have to find a proof of play that matches the seed that the player had been issued. In many games, a proof of play can be formed by submitting the game's solution to the server with the high score submission, in others it may be necessary to record the entire game session in various level of details depending on the game and the proof of play you're using.

A proof of play need to be replay resistant (one player should not be able to use another player's finished game to make their own proof of play easier to compute). This limits proof of play to games where there's some randomness that players cannot just reuse another player's proof of play, but also it cannot have too much non deterministic behavior to the point where verifying the play becomes impossible.

Proof of play is also limited. For example, in a Sudoku game, it's not possible to prove the amount of time the player take to solve the puzzle. Proof of play also cannot always distinguish between game played by the player themselves vs the player having written a script that played the game for them.