Security considerations with online browser-based games
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I would like to get some information or at least areas to research in regards to browser based game security.
I am new to this area of development, I am working with the MEAN stack and have basic knowledge with server side security, but am looking for the correct ways and procedures to focus my research on with regards to games.
As i understand i will need the game classes and data to be server side with a vast amount of validation prior to sending down the changes back to the clients but this is where my knowledge stops. I have been researching this topic and find that I am able to find information on general video game security but not in relation to browser games.
My question is what security considerations do i need to make for an online turn based browser game.
javascript web browser mean
asked Nov 16 '18 at 13:46
user3366235user3366235
113
add a comment |
I would like to get some information or at least areas to research in regards to browser based game security.
I am new to this area of development, I am working with the MEAN stack and have basic knowledge with server side security, but am looking for the correct ways and procedures to focus my research on with regards to games.
As i understand i will need the game classes and data to be server side with a vast amount of validation prior to sending down the changes back to the clients but this is where my knowledge stops. I have been researching this topic and find that I am able to find information on general video game security but not in relation to browser games.
My question is what security considerations do i need to make for an online turn based browser game.
javascript web browser mean
asked Nov 16 '18 at 13:46
user3366235user3366235
113
add a comment |
I would like to get some information or at least areas to research in regards to browser based game security.
I am new to this area of development, I am working with the MEAN stack and have basic knowledge with server side security, but am looking for the correct ways and procedures to focus my research on with regards to games.
As i understand i will need the game classes and data to be server side with a vast amount of validation prior to sending down the changes back to the clients but this is where my knowledge stops. I have been researching this topic and find that I am able to find information on general video game security but not in relation to browser games.
My question is what security considerations do i need to make for an online turn based browser game.
javascript web browser mean
asked Nov 16 '18 at 13:46
user3366235user3366235
113
I would like to get some information or at least areas to research in regards to browser based game security.
I am new to this area of development, I am working with the MEAN stack and have basic knowledge with server side security, but am looking for the correct ways and procedures to focus my research on with regards to games.
As i understand i will need the game classes and data to be server side with a vast amount of validation prior to sending down the changes back to the clients but this is where my knowledge stops. I have been researching this topic and find that I am able to find information on general video game security but not in relation to browser games.
My question is what security considerations do i need to make for an online turn based browser game.
javascript web browser mean
javascript web browser mean
asked Nov 16 '18 at 13:46
user3366235user3366235
113
asked Nov 16 '18 at 13:46
user3366235user3366235
113
edited Nov 16 '18 at 13:55
user3366235
asked Nov 16 '18 at 13:46
user3366235user3366235
113
asked Nov 16 '18 at 13:46
user3366235user3366235
113
asked Nov 16 '18 at 13:46
user3366235user3366235
113
113
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You will need to assume that the client lies to you. In everything.
You will need to second guess everything the client sends you.
For example: Lets say the chess client sends you "The black player wants to move his rook A1 to A4"
You need to make sure
- that whoever sent this actually is the black player.
- It is their turn.
- there is a rook on A1 and it is black.
- a rook is actually allowed to make the move A1 to A4 (in this case yes, what if it was a bishop?)
- nothing is on A2 and A3 and if A4 is occupied it's a white playing piece.
- by giving up A1, the black king is not in danger of being taken by a white piece
Now, a good user interface would check all this on the client. And the users will expect that. But despite all those checks, the client can still in the end lie to you. Because once your code gets transferred to the client computer, the player on the other end can alter it to whatever they like.
So remember the first law of game security: The client is in the hands of the enemy.
answered Nov 16 '18 at 14:02
nvoigtnvoigt
50.5k85794
This makes sense, so you are saying that i should perform checks for all the scenario's you gave on client? wouldn't that be dangerous in that they could find ways to overwrite them? I forgot to mention I am working with web sockets and each game is running through memory. I was also a bit more interested in preventing more complex game issues like handling a user being able to use the dev tools in a browser to cheat or using network lag to prevent other players taking their turn
– user3366235
Nov 16 '18 at 14:11
@user3366235 That is exactly my point: You cannot. Your user will be able to manipulate the frontend as they wish, so you need to make sure that you don't rely on what your frontend sends you. If a user sends you a command, make sure it's valid. Without a concrete game it's hard to say anything specific, but basically check all the rules on both sides, the client (for convenience and user experience) and the server (to make sure nobody cheats).
– nvoigt
Nov 16 '18 at 14:34
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53339115%2fsecurity-considerations-with-online-browser-based-games%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You will need to assume that the client lies to you. In everything.
You will need to second guess everything the client sends you.
For example: Lets say the chess client sends you "The black player wants to move his rook A1 to A4"
You need to make sure
- that whoever sent this actually is the black player.
- It is their turn.
- there is a rook on A1 and it is black.
- a rook is actually allowed to make the move A1 to A4 (in this case yes, what if it was a bishop?)
- nothing is on A2 and A3 and if A4 is occupied it's a white playing piece.
- by giving up A1, the black king is not in danger of being taken by a white piece
Now, a good user interface would check all this on the client. And the users will expect that. But despite all those checks, the client can still in the end lie to you. Because once your code gets transferred to the client computer, the player on the other end can alter it to whatever they like.
So remember the first law of game security: The client is in the hands of the enemy.
answered Nov 16 '18 at 14:02
nvoigtnvoigt
50.5k85794
This makes sense, so you are saying that i should perform checks for all the scenario's you gave on client? wouldn't that be dangerous in that they could find ways to overwrite them? I forgot to mention I am working with web sockets and each game is running through memory. I was also a bit more interested in preventing more complex game issues like handling a user being able to use the dev tools in a browser to cheat or using network lag to prevent other players taking their turn
– user3366235
Nov 16 '18 at 14:11
@user3366235 That is exactly my point: You cannot. Your user will be able to manipulate the frontend as they wish, so you need to make sure that you don't rely on what your frontend sends you. If a user sends you a command, make sure it's valid. Without a concrete game it's hard to say anything specific, but basically check all the rules on both sides, the client (for convenience and user experience) and the server (to make sure nobody cheats).
– nvoigt
Nov 16 '18 at 14:34
add a comment |
You will need to assume that the client lies to you. In everything.
You will need to second guess everything the client sends you.
For example: Lets say the chess client sends you "The black player wants to move his rook A1 to A4"
You need to make sure
- that whoever sent this actually is the black player.
- It is their turn.
- there is a rook on A1 and it is black.
- a rook is actually allowed to make the move A1 to A4 (in this case yes, what if it was a bishop?)
- nothing is on A2 and A3 and if A4 is occupied it's a white playing piece.
- by giving up A1, the black king is not in danger of being taken by a white piece
Now, a good user interface would check all this on the client. And the users will expect that. But despite all those checks, the client can still in the end lie to you. Because once your code gets transferred to the client computer, the player on the other end can alter it to whatever they like.
So remember the first law of game security: The client is in the hands of the enemy.
answered Nov 16 '18 at 14:02
nvoigtnvoigt
50.5k85794
This makes sense, so you are saying that i should perform checks for all the scenario's you gave on client? wouldn't that be dangerous in that they could find ways to overwrite them? I forgot to mention I am working with web sockets and each game is running through memory. I was also a bit more interested in preventing more complex game issues like handling a user being able to use the dev tools in a browser to cheat or using network lag to prevent other players taking their turn
– user3366235
Nov 16 '18 at 14:11
@user3366235 That is exactly my point: You cannot. Your user will be able to manipulate the frontend as they wish, so you need to make sure that you don't rely on what your frontend sends you. If a user sends you a command, make sure it's valid. Without a concrete game it's hard to say anything specific, but basically check all the rules on both sides, the client (for convenience and user experience) and the server (to make sure nobody cheats).
– nvoigt
Nov 16 '18 at 14:34
add a comment |
You will need to assume that the client lies to you. In everything.
You will need to second guess everything the client sends you.
For example: Lets say the chess client sends you "The black player wants to move his rook A1 to A4"
You need to make sure
- that whoever sent this actually is the black player.
- It is their turn.
- there is a rook on A1 and it is black.
- a rook is actually allowed to make the move A1 to A4 (in this case yes, what if it was a bishop?)
- nothing is on A2 and A3 and if A4 is occupied it's a white playing piece.
- by giving up A1, the black king is not in danger of being taken by a white piece
Now, a good user interface would check all this on the client. And the users will expect that. But despite all those checks, the client can still in the end lie to you. Because once your code gets transferred to the client computer, the player on the other end can alter it to whatever they like.
So remember the first law of game security: The client is in the hands of the enemy.
answered Nov 16 '18 at 14:02
nvoigtnvoigt
50.5k85794
You will need to assume that the client lies to you. In everything.
You will need to second guess everything the client sends you.
For example: Lets say the chess client sends you "The black player wants to move his rook A1 to A4"
You need to make sure
- that whoever sent this actually is the black player.
- It is their turn.
- there is a rook on A1 and it is black.
- a rook is actually allowed to make the move A1 to A4 (in this case yes, what if it was a bishop?)
- nothing is on A2 and A3 and if A4 is occupied it's a white playing piece.
- by giving up A1, the black king is not in danger of being taken by a white piece
Now, a good user interface would check all this on the client. And the users will expect that. But despite all those checks, the client can still in the end lie to you. Because once your code gets transferred to the client computer, the player on the other end can alter it to whatever they like.
So remember the first law of game security: The client is in the hands of the enemy.
answered Nov 16 '18 at 14:02
nvoigtnvoigt
50.5k85794
answered Nov 16 '18 at 14:02
nvoigtnvoigt
50.5k85794
answered Nov 16 '18 at 14:02
nvoigtnvoigt
50.5k85794
answered Nov 16 '18 at 14:02
nvoigtnvoigt
50.5k85794
50.5k85794
This makes sense, so you are saying that i should perform checks for all the scenario's you gave on client? wouldn't that be dangerous in that they could find ways to overwrite them? I forgot to mention I am working with web sockets and each game is running through memory. I was also a bit more interested in preventing more complex game issues like handling a user being able to use the dev tools in a browser to cheat or using network lag to prevent other players taking their turn
– user3366235
Nov 16 '18 at 14:11
@user3366235 That is exactly my point: You cannot. Your user will be able to manipulate the frontend as they wish, so you need to make sure that you don't rely on what your frontend sends you. If a user sends you a command, make sure it's valid. Without a concrete game it's hard to say anything specific, but basically check all the rules on both sides, the client (for convenience and user experience) and the server (to make sure nobody cheats).
– nvoigt
Nov 16 '18 at 14:34
add a comment |
This makes sense, so you are saying that i should perform checks for all the scenario's you gave on client? wouldn't that be dangerous in that they could find ways to overwrite them? I forgot to mention I am working with web sockets and each game is running through memory. I was also a bit more interested in preventing more complex game issues like handling a user being able to use the dev tools in a browser to cheat or using network lag to prevent other players taking their turn
– user3366235
Nov 16 '18 at 14:11
@user3366235 That is exactly my point: You cannot. Your user will be able to manipulate the frontend as they wish, so you need to make sure that you don't rely on what your frontend sends you. If a user sends you a command, make sure it's valid. Without a concrete game it's hard to say anything specific, but basically check all the rules on both sides, the client (for convenience and user experience) and the server (to make sure nobody cheats).
– nvoigt
Nov 16 '18 at 14:34
This makes sense, so you are saying that i should perform checks for all the scenario's you gave on client? wouldn't that be dangerous in that they could find ways to overwrite them? I forgot to mention I am working with web sockets and each game is running through memory. I was also a bit more interested in preventing more complex game issues like handling a user being able to use the dev tools in a browser to cheat or using network lag to prevent other players taking their turn
– user3366235
Nov 16 '18 at 14:11
This makes sense, so you are saying that i should perform checks for all the scenario's you gave on client? wouldn't that be dangerous in that they could find ways to overwrite them? I forgot to mention I am working with web sockets and each game is running through memory. I was also a bit more interested in preventing more complex game issues like handling a user being able to use the dev tools in a browser to cheat or using network lag to prevent other players taking their turn
– user3366235
Nov 16 '18 at 14:11
@user3366235 That is exactly my point: You cannot. Your user will be able to manipulate the frontend as they wish, so you need to make sure that you don't rely on what your frontend sends you. If a user sends you a command, make sure it's valid. Without a concrete game it's hard to say anything specific, but basically check all the rules on both sides, the client (for convenience and user experience) and the server (to make sure nobody cheats).
– nvoigt
Nov 16 '18 at 14:34
@user3366235 That is exactly my point: You cannot. Your user will be able to manipulate the frontend as they wish, so you need to make sure that you don't rely on what your frontend sends you. If a user sends you a command, make sure it's valid. Without a concrete game it's hard to say anything specific, but basically check all the rules on both sides, the client (for convenience and user experience) and the server (to make sure nobody cheats).
– nvoigt
Nov 16 '18 at 14:34
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53339115%2fsecurity-considerations-with-online-browser-based-games%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
