Trustable communication between your server and the browser?

I’ve always been having this problem in mind and always went with the easier more solution of doing it on the server. However, I decided I can ask more people about it, may be one of the enlightened can help me with a reliable solution.

Problem: you’re developing a web application that servers many users. Part of the features you offer involves calling an external API. That call is done for each user. The call can be made by either your server or the browser’s JavaScript. In either cases you persist the result of processing the data from the API call in the server’s database. I would like to offload calling the API and processing the results to the browser’s JavaScript and after it finishes it will callback the server with the data to persist. The problem that I see with 开发者_Python百科this approach is that anyone can modify that JavaScript’s behavior (how easy is that thnx to firebug and its likes) to persist malicious/incorrect data on the server.

How can I - the server - trust that the data coming to me from JavaScript - following the previous scenario - is correct and not altered?

The simple answer is you can't, JavaScript is the least secure mechanism in the pipeline - the easiest to manipulate. If you want it to be secure, you should never rely on JavaScript for it.

Think of it in a more general sense: you can only secure an environment you at least somewhat control...you have no control over the browser, the JavaScript engine, or the user manipulating it.

Always validate server-side, always, always, always.

If you want to create some data on server A, give it to a client, and have that client pass it to server B verbatim, then you simply need to include an anti-tamper hash with it. Server A and B share a secret which they use as salt. As the client doesn't know this salt, it is unable to fabricate authentic data for itself.

Note that on its own, this technique only gives a strong degree of confidence that server A originated the data. There are other vulnerabilities you may need to consider, such as replay attacks of old data etc.