In preparation for the Nordic Tour, we are exploring the range of private to public APIs. A very important part of that is APIs for mobile applications. A large majority of iPhone apps relying on an API for communication with a back-end system, and even the simplest apps often use an API of some sort. At the same time, it is very easy to see what network traffic takes place between such a mobile app and the server. This allows third-party developers to see how the app’s API work, even if it isn’t documented. This means that your “private” API for your mobile application is actually a thinly veiled public API.

How to Intercept the Traffic

There are several tools to do this. The one I prefer is Charles Proxy, and quite easy to configure. (This is a great article about how to do it.) Basically, you will send all the traffic to and from your phone via a proxy on your computer. By installing some certificates, Charles (or other proxy tools) can also intercept SSL encrypted traffic and show it as plain text. SSL is good, but in this case it actually does nothing.

Example

Let’s take a look at a couple of examples. First out is the Copenhagen airport Phone app. A quick check in Charles Proxy makes it clear that the app request data via a POST from cph.novasa.com/json-rpc/?service=cphdata with parameters in the body of the request and that they are using HTTP Digest for authentication.

This can be done to any mobile application. It has already happened to Instagram, SJ, a Swedish train operator (in Swedish), numerous banks, and others.

Security Implications

The main implication is that “security through obfuscation” is, as always, a bad idea. Especially when the obfuscation can be side stepped in a few minutes. Be aware that anyone can see how your API is designed, what API credentials (API keys for example) you use, and what data is sent back and forth. If the API really is handling super sensitive data, it should probably not be in an mobile app to begin with.

Even if others can see the traffic between their phone and your server, it does not mean that unauthorized users should be able to easily use your API. Avoiding this comes down to your APIs security scheme. If you are using API keys, HTTP Basic, or similar, all the credentials will be easily available. Thus, anyone can use your keys to access your API. Creating a proper API security scheme to avoid this will be one of the topics we’ll delve into during the tour. Security experts from Twobo and Axway will be among those presenting to help shed some light on this challenging aspect of APIs.

What to do about this?

The first thing to do is NOT TO PANIC. If your “private” application’s API gets documented on GitHub and used by developers, you have a great confirmation that there is a market for a public API. It is market research and should be treated as such. Try to see traffic interception as an opportunity and not a threat. Design your API as if it would be public even if you just plan to use it in your own mobile app.

The alternative is to optimize your private API for your own use case. If you do this, you still need to be aware that others might use your API. If they do and their app becomes wildly popular, do you really want to break their app by changing your private API? Perhaps not, in which case you may find yourself stuck supporting a less-than-ideal API.

Want to know more about APIs, especially about how to get the most out of both public and private APIs? Then please join us during our Nordic APIs tour in April when we come to Copenhagen, Helsinki and Oslo.