I know that Javascript is an incredibly unsecure way of programming a persistent game, where for instance you are doing battle calculations in an RPG and then award XP through linking to a PHP page when they win that adds XP to a database (since the player could make their own javascript to always win or just look at the PHP page that you get sent to when you win and just go there anyway).

So with that said, I'm wondering if HTML5 makes multiplayer/persistent games any safer in this regard, since I know it still uses Javascript. Or am I still doomed to rely entirely on server-side scripting for doing any calculations that award the player?

I know that Javascript is an incredibly unsecure way of programming a persistent game, where for instance you are doing battle calculations in an RPG and then award XP through linking to a PHP page when they win that adds XP to a database (since the player could make their own javascript to always win or just look at the PHP page that you get sent to when you win and just go there anyway).

So with that said, I'm wondering if HTML5 makes multiplayer/persistent games any safer in this regard, since I know it still uses Javascript. Or am I still doomed to rely entirely on server-side scripting for doing any calculations that award the player?

• php
• javascript
• html

4 Answers 4

Anything that's not on the server is inherently insecure. After all, it only takes a telnet connection and the user can send literally anything they want to your server.

In short, you can't trust anything sent from the client, so the answer is yes - you gotta do the work on the server side.

Unfortunately, HTML5 doesn't change these basic properties in any way. So no, you have to do it all server-side.

No matter what the game, whether JS or native binary, if the scoring system is vulnerable, people will tamper if the game is good enough. Stick to clever serverside every time.