API Security – Proposed Method to Restrict API Access to Mobile App Only

androidapimobilerestSecurity

I read a lot that you can't restrict your Public REST API to only your mobile application, but I have an idea and I want opinions on it:

Variable App Key Method

Mobile App

  1. Get IP address of current connection
  2. Use a secret algorithm to generate a hashed AppKey from IP address.
  3. Send the AppKey with each API request

Server Side

  1. Check the IP address of incoming request
  2. Generate AuthKey from that IP address using same secret algorithm.
  3. Compare AuthKey with AppKey, if they match then you know that your
    Application is talking to you, because only the application knows
    the secret algorithm.

When IP address changes:

  • On mobile App regenerate the AppKey using the new IP address
  • Server side will always generate same key because it depends
    on IP address of the request

The main advantage of this is that the AppKey will always change, which is better than hardcoding 1 application key inside the code, which can be easily stolen by reading request headers. And even if you stole the AppKey from a user you must be using the same IP address where that key was generated.

Any thoughts?

Conclusion:

Relying on the IP address is problematic because you will need to call an external API to return back your correct IP address, and you will have to do that before every request because IP addresses change all the time.

Second problem is that internet connection on mobile switches a lot from WiFi to 3G to 4G, which will lead to unstable application behavior.

Best Answer

Although it is certainly the case that generating a dynamic access key based on the IP address will improve protection, there are a number of problems with this approach:

  1. You can't actually assume that the IP address of a mobile device is very stable. This would mean that the IP address could change and then cause the requests to be rejected. Moreover, you need to query another service via an API to even find out the public facing IP address of the device is (it doesn't know because it might be behind NAT). Certain modern mobile networks can load balance requests address multiple IP addresses, which may mean you get a different external IP for each request.

  2. The algorithm to calculate the key can be reverse engineered from your app and then abused. So you still need to worry about how well protected it is.

  3. Probably the most important of all, this doesn't actually protect abuse from the same IP address (e.g. devices on the same network behind NAT). An attacker simply needs to capture the good AppKey by a Man-in-the-Middle attack and then they could use it any script or other apps they wanted successfully from the same IP address.

In my opinion, the better approach is to embed a secret in the app which can then be used in an HMAC calculation along with the API request parameters to show that the request is coming from your app. Of course, you are still subject to the possibility of this secret being reverse engineered from your app. There are then a whole series of different protections you could use to try and prevent that.

I work for a company that specialises in exactly this area - protecting backend APIs that are used by mobile apps so that they can only be used by the official app. You would be surprised the types of business attacks that can be mounted by spoofing requests and the lengths that some attackers will go to in order to mount such attacks. We have a very detailed blog series here that walks you through all the different levels of protection that you can apply in your app that I think you will find useful: https://www.approov.io/blog/practical-api-protection-walkthrough-part-1.html

Related Topic