How do you protect a non-public web API from a malicious app where a developer has discovered how to perform some requests?

Take Instagram's app as an example: Instagram does not have a public API request to POST media. Their policy has been to only allow users to post via the official Instagram app.

However, there are services that allow seems to have been able to POST media from outside the app. I would assume an ambitious developer managed to decompile the iOS or Android app and discover the requests that enabled POST-ing media. Thus, this developer has the ability to spam Instagram with automated posts.

I would also assume Instagram would have attempted in some way to protect their API via either an API key stored in the app or by some other means.

My question is: How do you protect an app against this kind of attack, and if you cannot absolutely protect against this, what are the next best options?


1 Answer 1


If you're running a web service, you must always assume that the client-side of your service can never be secured against user tampering. Everything you send to the user can be reverse engineered, it's just a matter of time.

The solution to this is to do your security checks on the server side instead. In your example of spamming Instagram posts, they likely prevent this by rate-limiting calls to their API. For example every user is only allowed to post, say, 2 pictures per minute, and any API calls attempting to post more than that would result in a failed post, and return a 400-series HTTP error.

So in your Instagram example, they really cannot prevent anyone from sending their own API requests. Therefore they must be doing server-side validation of the API requests that they receive to make sure they are all legitimate and that the API is not being abused.

  • Thanks for replying. If I may provide another scenario: A developer creates a fake version of a banking mobile app and somehow managed to convince the original user to install the fake app on his device. This fake app would request for auth credentials (ie. accnt # and password) and then subsequently make POST request to, say, transfer money to another account.
    – ryd3r
    Commented Dec 10, 2015 at 4:31
  • You didn't ask a question there @ryd3r, but I suspect your asking if that's possible. The answer is sure. Problems like this are why app stores have rules and mobiles restrict installation to the app stores. Not that that is perfect, but they try. Commented Dec 10, 2015 at 4:43
  • Yes, that's right. Would anyone be able to suggest what strategy banking apps currently use to (attempt to) secure their apps?
    – ryd3r
    Commented Dec 10, 2015 at 4:50
  • 5
    @ryd3r Don't think of it as the banking app or API being insecure, it's the user putting their login credentials into piece of malware that's insecure. If an attacker gets a user to install their rogue app and put in their banking username and password, the attacker can just record the credentials and log in to the user's account, API or no API. Commented Dec 10, 2015 at 5:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .