At a glance I can identify some weaknesses in your code:
- You are not using HTTPS. Traffic between the client and server could be intercepted and seen in clear.
- You are not using prepared statements. While
real_escape_string
is probably ok, know that: 1) It is altering the data. 2) It depends on the character set configured for the database connection (which you do not seem to be setting).
- You are not validating user registration (i.e. sending an email with a code and waiting for it to confirm). Which means that it is easy to create lots of fake accounts.
What you ask seem to be authenticating your application to the server. The server does not know if the client is valid (it could be third party software doing the requests), so you want to find a way to make sure.
No, there is no way to do it. Not if the user is in control of the client and can reverse engineer it.
Fredrik Sch?n answer offers an solution that is useful in a different context. The idea is there will be a "password" apikey
that identifies your application, and the server will check if it is correct. This is useful if I want two applications to connect... however, when one application is on the user machine, this is not secure at all.
Remember that your client could be modified, or the apikey
stolen, since it is running on the client machine.
You could add a digital signature to the client (to add an integrity check on your client, so that it can verify that it has not been modified), yet that can also be circumvented.
On this point, it is all mitigations. There is no way to do it.
hack the Game data Like (Score, Total play, Time play, Otherss data).
Never trust the client
There should be no API to do these. There should be no way for the client to set the score (or to set any other form of reward). Instead the client sends events to the server (they can be as granular as one per user input, this is what you would be doing on a multiplayer client-server game anyway), and the server decides on score, rewards, etc.
I repeat, there would be no API. There would be no way for the client to just send how much you played.
Removing the process is the only way to guarantee you removed a risk. Otherwise, it is all mitigations.
A search for Anti-Cheat at gamedev.stackexchange.com can give you some ideas.
Addendum:
The problem of a game client that accesses a web form and a malicious user that creates a custom client that accesses the same form... is not fundamentally different from the problem of a web browser that accesses a web form and a malicious user that creates a custom client that accesses the same form. All server side security measures for the web apply for the game. And please notice that basing this security on a particular browser is not a good idea.
What we want is not to prevent the creation of the third party custom client, nor to make it useless. Instead to make sure it can at best do the same things that the legitimate client can do.
There is an API between the client and the server. If there is something in that API that allows the client to do something that the client should not do (such as setting a fake score), then the server and its API must be reworked so that it is not possible.