REST - How to restrict access for not authorized client software

Question

here is the challenge:

The service-/business layer has a REST (JSON) interface. There are two kinds of clients which can call the API: The webapp, which is running in a

Answer 1

Unfortunately, my response is that you should simply never trust the client application(s).

While there are various ways to create a trust relationship with the client you have distributed, all of them can be hacked, cracked, or bypassed. Never trust any data coming from outside your server. Ever. Never rely on connections to be coming from your client or a major web browser. Everything can be spoofed with enough time and effort.

Some good examples of issues like this in the industry are easily seen from things like gaming, where even with routines to check for memory hacks and other approaches, eventually even services with huge budgets like World of Warcraft often see either hacks of their client appear or outright client emulators capable of sending commands the normal client would not. Relying on your client software to remain secure and only ever send proper data to your server is a recipe for disaster. Always validate server side if it is for something important. Always properly escape/parameterize data. Use whitelist models, and preferably use symbol table lookups based on user input instead of user data itself where appropriate. Etc. Client side validation should only ever be seen as helping the user, not as something secure.

If you are simply going for "good enough" then you may have some options to help reduce the likelihood of seeing this happen, such as a security through obscurity solution like you proposed, but you should never rely on it not happening, even then.

One solution is to basically not include the major functionality of the client within the client, but instead send it from the server (javascript/etc) at runtime, with a different fingerprint for each time you send your logic package to the client, possibly with a range of different logic routines, with one randomly picked. You can then timeout the packages, track which user accessed which package, and have the package return telemetrics which you also use to help maintain security. Any mismatch between returned logic and what was sent with the fingerprint can immediately be assumed to be a spoof or hack attempt. Ultimately, however, all of this can still be beaten (a relatively rudimentary example like this can be beaten rather easily by someone determined, especially if you don't have runtime memory security).

There are a number of ways to deal with man in the middle (MITM) attacks, where someone is trying to intercept data, but none of them can fully account for a compromised endpoint.