Securing HTTP data from a JavaScript game to server

Suppose I am doing a JavaScript game, and I wish the game to update the server if the user has successfully completes the game and his outcome.

How should I ensure that the request came from the JavaScript game, and that the data sent has not been tampered with. I am using PHP as the server-side language.

I do understand that no strategies are going to be 100% fool-proof, and any measures taken is more of a deterrence than absolute protection.

On Edit: Let's supposed we're not using server verification of each user's step (as in a traditional MMO). The game could be a mini-game as part of a web game or educational game (space invaders or a real-time game, for example) and requiring a server-side component for each of those games could be tedious.

Example: Supposed, when the game is completed, a request is sent to the server via. AJAX

game_finished.php?user_id=1&outcome=success&score=88


A user could 'fake' the server in believing that the game has been completed correctly by sending that request to game_finished.php. How could this be made more difficult?

a sliding block puzzle, for example

This is an example where server-side verification is trivial. It doesn't need to verify each step until the game is over. Just send the entire move list, and the server replays it to make sure it's correct.

(Edit: The point of this answer isn't to pick on examples until you find one that isn't trivially validatable. Rather, it should make you go back and look at the game you're actually making - it's probably trivially validatable, or only needs a small tweak to be.)

• I was thinking over the example and it isn't the best of examples. Let's say Space Invaders then. I will update the question. – Extrakun Oct 26 '10 at 16:56
• The movement of Space Invaders is also totally deterministic, though. You just need to record when each shot/hit pair occurs, simulate movement up to that time (which is a simple linear equation), and make sure it was actually a hit. – user744 Oct 26 '10 at 17:00
• I finally got what you mean after thinking it through. Thanks – Extrakun Oct 26 '10 at 17:14
• Just an addition to the "totally deterministic" aspect: If you need randomness in your game, pass a specific seed for that randomness to the client and save that seed on the server. When the client sends the gameplay log for confirmation, the server can replay the parts that involve randomness as well. The same is possible for steps that depend on the local time. See Undum's (undum.com) save and load algorithms as an example of how this can be done in JavaScript. – BerndBrot Aug 21 '12 at 19:19

You can do it the Warcraft way: Use Javascript only for sending movement commands to the server, and let the server handle logic.

This still leaves you open to robots (javascript programs that move things faster an more precisely than humanly possible) but that's a big step compared to leaving the door open to the /game_finished.php trick.

If you are having the client calculate the score, there is no way to validate it beyond (as pointed out) having the server replay the game to confirm it gets the same score.

There are though types of games you can design that don't work based on just a numeric score. A server side script can generate a random addition math problem for example, and when the user submits the answer it can compare their answer with the correct one and score it server side.

But if your game is a complex one (like the space invaders example), there's not much you can do about it beyond either a) trusting the client, or b) letting the server manage the game.

There are many methods, but all of them will fail eventually. You can add some hash value, or query key renewed with every query.

But the most important thing is, that all of your super encoding functions are send as source codes to clients' browser and that is THE problem. To make it little harder, you can use function send by Ajax query, so sources won't be available under an url. Function should be send compressed, and maybe even in parts, so it will be harder to copy it all. I would also check this code in page like http://jsbeautifier.org/ if after making it readable your code is easy to understand.