Benjamin Smith
Benjamin Smith

Reputation: 887

API for mobile app security/auth

I have an API that is serving content to a mobile app, and have no current plans to use the API for other products. I have 2 main questions:

  1. How to prevent someone from sniffing the API requests and making their own requests (this should not be an public API).
  2. If preventing #1 is not possible completely, then how can I limit/throttle requests from un-approved consumers? Are there other concerns here?

Using an auth token (passed as A GET param) for each request satisfies #2 (I can revoke it at anytime) however I do not want to have to update the app to use a different token in future.

Also, there is no authentication for users in the mobile app, and the API is written in PHP.

What are the best practices in this area?

Upvotes: 0

Views: 776

Answers (2)

MarkO
MarkO

Reputation: 11

  • How to prevent someone from sniffing the API requests and making their own requests (this should not be an public API).

I would echo the previous answer that you should use TLS as a matter of course, in order to encrypt the traffic on the wire to prevent sniffing. But I would add that you also need to deter "capture-replay" attacks, whereby an attacker may resend a previous message which they may have obtained (e.g. from a client-side log) despite the usage of TLS. In this case, if you are using a nonce (meaning "number once") and/or timestamp in your requests, with HMAC signing, then the replayed API request can be detected and blocked. I have written about an example of this on my blog: http://www.soatothecloud.com/2011/02/securing-apis.html . Amazon's APIs, for example, use this approach.

  • If preventing #1 is not possible completely, then how can I limit/throttle requests from un-approved consumers? Are there other concerns here?

As well as the HMAC signing (above), you can also consider monitoring incoming IP address range, device info (e.g. headers indicating the device type - Android vs iOS etc), and other factors which can be used to link multiple requests to particular clients, and then apply policies at the API level.

Full disclosure: I work for an API Management / API Gateway vendor (Axway) but the info above should be generic.

Upvotes: 1

James Holderness
James Holderness

Reputation: 23021

Here are a couple of suggestions that can help keep your API private.

  • Use TLS to discourage casual packet sniffing.
  • Make sure your clients verify the server certificate to prevent MITM attacks.
  • Encrypt or obfuscate the auth token in the client code so it's not obviously exposed in something like a string dump.

Ultimately, though, if someone really wants to access your API, they will - either through reverse engineering your client code, or more complex data interception techniques. The best you can hope for is to discourage access attempts by the average user.

Upvotes: 3

Related Questions