4 Ways API and Mobile App Development Teams Can Work Together To Ensure Security

Mobile represents new risks and unique attack vectors that require the focus of the whole organization, not just one team

Underwriters Laboratories (UL) rates safes on the length of time it would take an attacker with normal tools to break in and steal your valuables. In addition, most safes are bolted to the floor from within the inside of the safe. Both of these highlight the important truth that when it comes to security, there’s almost nothing to stop an attacker with physical access and enough time.

Software is absolutely no different. Just like a physical safe, any attacker with physical access and time can break into anything and there is simply no solution that can’t be broken eventually. Your API team already knows this – which is why companies like Google have notoriously locked down server rooms to prevent physical access.

But there is nothing your mobile app team can do to prevent physical access. We take our phones with us everywhere we go and they are easily left somewhere, dropped or stolen. Since you can’t prevent physical access, every piece of security must be examined through this lens.

Here are four ways for your API and mobile app teams to work together to reduce risk:

1. Store as little as possible on device

Your API should work without any locally stored information. Anything that can be moved up to the server and behind the physical security should be. This relates to obvious things like a password or social security number, but also extends to simply unnecessary things like first and last name. If the server knows it, don’t make a weird process where you need to re-enter it. There will be an obvious temptation to store things to work around API inconsistencies, but these inconsistencies can easily open security holes.

Even things that you treat as innocuous and publicly safe may still be risky. Wired’s Mat Honan had his Apple account hacked by someone who obtained the last 4 digits of his credit card from Amazon and used those 4 digits to unlock his Apple account. One service’s innocuous data is another service’s unlock code. You can sidestep the entire question by simply not storing things unnecessarily.

2. Don’t assume secrets can be hidden

Anyone can download your app and their phone can be modified in many ways – jailbroken (iOS), rooted (Android), etc. This means that if your app needs to load a string into memory to send to an API, it will be seen. This is different from server-to-server API calls, where the other server might be trusted to keep a secret key hidden. I’ve seen developers try to do all sorts of gymnastics to load a secret key somehow into the app bundle in an obfuscated way, but at the end of the day, you have to load it to a string and send it on the wire. Physical access means there’s no way to plan for this beyond simply making sure it’s not necessary.

3. Plan for compromised data

When you plan for different contingencies, you should take both of the above into account. Assume that anything you did need to store has definitely been compromised – what are the steps for dealing with that risk? If an OAuth token was revoked, how does your app deal with that while it’s running, while it’s waking from background, or while it’s launching from full stop? What is the process on the server to re-validate and how does that affect the app? Have you made sure open sessions are not slipping through?

4. Collaboration is key

All of these methods (plus additional best practices like certificate pinning and regular audits) are fruitless unless the two teams work collaboratively. Security is a concern for the whole organization and both teams should be focused on helping each other achieve the best possible results.