Have you ever installed an app in your Android phone and when you got to the permission screen you just couldn't justify to yourself why an app would require the permissions it's asking for? I have, and initially I thought it was just me until I ran into a white paper from Bit9 titled Pausing Google Play: More Than 100,000 Android Apps May Pose Security Risks. If you haven't freaked out yet, let me poke your side with this: this was based mostly on looking at the permissions the app is requesting at installation time.
They did not do any blackbox analysis of the apps themselves. Based on this, my experience reviewing code from a 3rd party mobile developer, and the type of questions that I've seen from some of the Android development forums out there, I don't even want to think how high that number would be. The white paper is geared more for enterprise IT professionals (like most of these things are), but it's an interesting read to help secure software developers in understanding the user landscape. What I really want to focus on is what can mobile developers do to help this disturbing trend.
Don't be permission happy
Make sure that you have fully evaluated whether your app really needs to use a particular service. Whenever you have to declare a new permission in the android manifest think first of whether you really need that permission. If you can't state exactly what feature needs a particular permission you're most likely doing something wrong, you're using the wrong Android API function, or worst using the wrong 3rd party tool or library.
Make sure to understand what you're using
Do you know where the data stored in the outState parameter of Activity::onSaveInstanceState() is stored? What is the lifetime of the data? When you save something in "Internal Storage" is it truly "private"? I once saw an app that stored the username and password in clear text. The developer claimed it was "safe" because it was stored in the file system using Context::openFileSystem() and they passed MODE_PRIVATE (which happens to be the default for this function) as the second parameter. Obviously the developer didn't know that ADB exposes the device's filesystem.
Make sure that a requirements document exists, and has been tested
I'm sure everyone understand the first part. We say and hear it more times than we bother to see if the moon is actually still there at night. The second part I can't think of the clearer way to state it, so let me explain a little bit. What I mean by the requirements has been tested is the requirements should have been reviewed from a QA perspective. There's more to secure software development than preventing buffer overflow, and preventing SQL injections. I believe that requirements play as large a part in securing an application than making sure that all inputs have been verified and being exception-safe.
The massive amount of effort and money being thrown in mobile app development is really just a variation of the same thing. People chasing the "next big thing". However, in this mad rush I hope that we learn the lessons of web 1.0 from a security perspective.
Cross-posted from Home+Power