HTML5 Multiplayer Game Security Solutions

Question

Now that there are a couple of neat canvas demo's of both classic platform and even 3D fps games in HTML5, the next step might be to try developing a multiplayer HTML5 game. HTML5 socket support makes this relatively straight-forward, but with client-side source being viewable by anyone in the browser, what are some solutions for basic game security features for a HTML5-frontend multiuser game -- such as being able to prevent a faked high-score submit?

Soukup

Answer 1

The simple answer is: You can't trust the data from client, which means that the high score submit can't come from the client.

Since the code client is available for anyone to inspect, there's no way of trusting the data that the client sends your server. Even if you encrypt the data with a per-user encryption key (which is possible), the user can simply alter your code within the browser and change the values it's sending to the server.

Since your game is multiplayer, this might be possible IF the server generates all the scoring events. If the server generates all the scoring events, the client never sends score data to the server which means that the high score data can't be faked.

You'll still have to deal with cheating, which is even more challenging, but that's another issue...

Schuyler

I'm still thinking of ways where server generating the scoring events might work... It seems that inevitably, the clientside would have initiate some feedback for the game to be interactive - such as clicking or pressing a button, which would ultimately be translated to just a socket/URL call, assuming each scoring process is sent to server. Since the URL to send this scoring event is out in the open (and there's no way to avoid this?), it seems like people can just easily abuse it by setting a scraper to the URL, even. What kind of game could have only server-confined scoring events? – Soukup

@ina: pretty much every commercial online game does all its scoring on the server. The client initiates the actions but the server resolves them and decides the outcome. – Orthographize

@ina: What kylotan said. Don't have a "generate a score" event. Have a "player took this action" event. If the action results in a score being generated, generate the score on the server. It means that your client is nothing more than a display for events generated by the server - there's effectively no gameplay elements executed on the client, they all happen on the server and are rendered on the client. – Schuyler

OK, so something like this? Server random generates "hit score possibility" with limited time and space window of valid user-generated "hit" (ie, click in some box, in the next 3 seconds...) Info sent thru server url though... so... with timeout, for the case where someone abuses the server call url by creating a super-pinging bot, for ex? – Soukup

You're over thinking it. Think of it this way: Client sends a "player attacked <other player>" message and starts the "player attacked" animation. Server decides if the player hit or not and sends a "you hit!" or "you missed!" message back to the client. The server keeps track of hit points, health, etc. When one player dies, the server sends a "you died" message to the dead player and a "you killed them" message to the killing player. All the stats and record keeping is on the server, the client does nothing but show UI. The same idea applies to other game types (poker, etc). – Schuyler

With <a href="dev.w3.org/html5/websockets/">WebSockets</a>, online browser games are possible. However, aimbots and non-graphical bots are still problems. Using random screenshots for anti-cheating? Browser security does not allow that. – Lithium

Answer 2

Adding on to what Larry said, you're definitely going to have to handle the scoring on the backend to really prevent cheating/fake score posting.

For an example of this in practice... The game Word Wars is a boggle-esque game where you find as many words as you can from a 4x4 grid of letters.

At the start of each game, a 4x4 board is generated server side. A list of possible words for that board is generated and a hashed version (md5'd with a random salt) of each word as well as the salt are passed to the client.

On the client side, when the letters are typed and the enter key is pressed, we md5 (with the salt from the server) the word that was entered and check that against the list of hashed words provided by the server. If it's a match, we update the client with the new score (there's a function based on letters used and their point values).

Once the game is over, the client sends the list of words they came up with to the server (NOT the score), and the server double-checks that those words existed in the board, and handles the scoring.

This is where Clay.io, the company I'm working in comes in. Clay.io offers an API for high level HTML5 game features like leaderboards, achievements, payment processing, etc... Needless to say, we needed a solution for games that have a backend to make certain things like high scores more secure.

The solution was to encrypt JavaScript objects on the backend (node.js, php, whatever) using JWT (JSON Web Token), and pass that encrypted object rather than the score itself. This lets us communicate both ways (game -> Clay.io and Clay.io -> game), and is pretty painless to do. The full docs on this are here: clay.io/docs/encryption (max links hit on this answer)

Back to Word Wars... from the server we generate that JWT with the user's score and pass that on to Clay.io to post the score. Voila :)

Of course, this will differ as the type of game you're developing differs, but the moral of the story is you have to get creative :)

I wrote a blog post that covers HTML5 game security in greater detail. Part 3 of a series on HTML5 Game Development Tips.

Tacit

Yeah, they'd be able to toss every dictionary word at the game and get somewhere... of course, you could check fail rates to see if someone is actually doing that. The one person who did 'crack' it just ended up building a boggle solver - no way around that unfortunately (just like there's no way for Words With Friends to prevent that sort of thing in a Scrabble-equivalent) – Tacit