gumshoe2029 exactly.
Just to make it more clear, I'd split it to three simple levels of security here.
1. No SSL, No API KEY
Any kid who fetch the URL, is able to send fake data.
2. No SSL, with API KEY
You need a solid JS knowledge and have a lot of patience to - let's call it - decrypt the minified JS code and understand the API KEY generation algorythm (which by the way might be way more complex than standard sha1(salt+data)) in order to send fake data. So 99.9% of kids are already filtered here.
3. SSL
The right way for securing the data transfer.
Kind of...
You have to think of security from a domain perspective, not an application perspective. In security there are five domains: confidentiality, integrity, availability, accountability and assurance of services.
A. SSL
Protects data from being accessed by anyone except you and your customer. (Except maybe the NSA who has internet trunk access and possibly SSL zero day vulnerabilities in hand). SSL falls under the confidentiality section.
B. API Key (HTTP sessions and cookies fall under this category also)
Ensures that the person who owns the account is actually the one who is talking to your server. (A form of authentication) API keys fall under the accountability section.
---------------------------------------------------------------------------------
So when you start combining things:
1. SSL + No API Key
You have a secure connection between you and each of your players, but you have no way to know which player is asking for which information in any given request.
2. No SSL + API Key
Assuming that your API key is very temporary (like a lifetime of only a minute or less) and regenerated frequently, you are likely to know which of your players is asking for information from your server at any given time, but without using SSL anyone who can get close to either your server or your user's local network can simply scrape the API key from the wire and submit as theirs.
3. SSL and API keys
The data between you and each of your players is secure and cannot be snooped, and you know which player is asking for information.
--------------------------------------------
However, none of this addresses the problem that the OP has, which is legit players who have both SSL and API keys submitting false data. All of the above only prevent OTHER players or hackers from pretending to be that player.
Like Ashley said, in raw JavaScript there is no way to prevent that, because your registered users have all of the SSL certificates and API keys necessary to submit data to your server, there is nothing stopping them from simply changing the data and submitting it to your server.
I know I probably sound like a broken record constantly saying, "You have to have a server side application," but it is not wrong. That is the ONLY way you can keep players from submitting false data (that I have found thus far).
For example, our API call: https://www.ravenheart.ca/dev0engine?op=moveFleet&fid={fleet_id}&pid={to_planet_id}&oid={to_orbital_id}
Let's say player 2, who is the owner of fleet #3 on planet ID 22 and in orbital 0 wants to move his fleet. All of this information is stored on our databases (which cannot be tampered with by anyone except my developers and the server).
If he submits a call like:
https://www.ravenheart.ca/dev0engine?op ... d=68&oid=2
The call will reply with an error, because I run all of the data through a series of checks on the server to ensure that the player actually owns the fleet, that the fleet exists, that the planet and orbital exist, etc. If any one of these checks fails, the user gets an error message and nothing changes on the server. They get the reply:[quote:26jx7d1m]{"2041":["Error: This fleet does not exist","You do not have this fleet in this planet's orbitals."]}
JS Minifying helps, but it does not take a lot of skill to see the debugger output all of the variables and simply identify which one is being submitted to your AJAX API and simply changing the value of that variable in the source at execution time.