How exactly do you prevent something like this? How do you ensure that the stats sent over the internet are coming from an actual approved client?
My instinct tells me the simplest solution would be security by obscurity - adding some validation token that the client generates by some obscure and hard to reverse engineer manner. Is there any better way to 'validate' your client?
> Use SSL for the requests which makes it harder to sniff the API.
Won't help - it's trivial to setup a proxy to MITM the traffic.
> Use a specific User Agent string and check for that.
Won't help - it's easy to manipulate a User-Agent. Assuming you're manually creating the GET request (via cURL or other means), then it's only one more option to bypass this.
> Provide no error messages if any of the above fails.
Will make debugging a pain. Also, if I'm an attacker, I'm going to try and clone the request as best as I can the first time, then see what I can get away with.
> Add some sort of tamper token like you suggest.
This is the best option. Not quite sure the best way to implement it, but perhaps some sort of CAPTCHA (this would be a pain), or some kind of random request id, etc. might work.
I would add to that: use a self-signed cert for the SSL. If you rely on the OS's PKI its relatively easy for an attacker to add their own CA and read the connection.
My instinct tells me the simplest solution would be security by obscurity - adding some validation token that the client generates by some obscure and hard to reverse engineer manner. Is there any better way to 'validate' your client?