ios - Django: Only accept requests coming from my applications

Question

Is it possible to only accept requests that our coming from my applications? Say for example I have an iOS app called 'Best App' and it uses Django as its backend. How can I make it so that only requests coming from Best App are accepted and everything else is rejected?

I was thinking of checking the 'HTTP_USER_AGENT' key in the request and if the HTTP_USER_AGENT is 'Best App', I will allow the request to go through. But I recently found out that anyone can modify their USER_AGENT from applications like Chrome and make requests to access our resources.

Is there any other way that I can restrict access just to my particular application? I would like to open up my backend service to other developers by giving white-list access. But for now, I would like to keep access to our back-end private.

Your advice and insight on this matter is greatly appreciated.

Answer 1

Good application security solutions are non-trivial. You cannot use any simple, plain-text object like HTTP_USER_AGENT. One common approach is an "API Key" - where a key that is obtained from a registration page is supplied along with the request, but unless you combine this with some other "secret" it can be trivially copied and supplied by the "false" app.

One reasonably strong solution would be some form of challenge/response using a shared secret. A determined attacker could, theoretically, extract your secret from your app and use it, but that requires a reasonable deal of effort - first they need to decrypt your app bundle and then extract the secret. The flow is something like -

1. App sends request to web service for authentication, supplying API key.
2. Web service looks up API key to determine "shared secret"
3. Web service sends challenge string back to app
4. App hashes challenge string using shared secret and sends it back to the web service
5. Web service applies same hash and compares answer
6. If hashes compare, web service returns session key to app
7. App sends session key with all subsequent requests
8. At some point you need to invalidate the session key - either app logout, timeout, number of requests

To protect this approach from man-in-the-middle attacks you need to run it over SSL and ensure that your app validates the server certificate.

You also should implement some form of protection against brute-force attempts, such as locking an API key after 'x' failed challenges