2 added 4 characters in body
source | link

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.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.

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.

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.

1
source | link

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.