The mobile environment is relatively secure – at least when compared to operating systems (OS) like Windows – and many of the statistics decrying Android as the Typhoid Mary of the mobile world (about 97% of all mobile malware is built for the platform) ignore the fact that gatekeeping by Google and the Play Store keeps out all but 0.01% of portable nasties. In other words, mobile malware doesn’t really exist for the average user.
.
However, the above doesn’t change the fact that security is a mandatory consideration in the development of some apps. While the obvious candidate is mobile banking, any piece of software that harvests customer data needs a way to deliver that information securely to its final resting place. But where does the budding developer start? Security issues certainly need resolving during an app’s planning stage.
.
Starting Out
The drawing board is the point when the designer will begin to answer questions like “does Android support X feature” or “is Y compatible with App Store review guidelines?” by researching OS guidelines, security policies, and target audiences. Developing an app that supports Apple Pay requires an appropriate certificate for example; that’s not something anybody wants to find out at the beta stage.
.
.
One of the biggest concerns developers face when coding an app is leaving vulnerabilities behind. On PC, many companies use web application security solutions to prevent hackers taking advantage of security flaws and using tricks like remote file inclusion to profit from their trade. However, in the early stages of mobile development, third-party review (e.g. a fellow coder) can provide a “sanity check” to catch the more obvious bugs.
.
Holding the Fort
.
It’s worth noting that Android does have its own security features that can take some of the pressure off mobile developers. For example, an application sandbox stops apps interfering with each other; user-defined permissions let the phone’s owner determine the limits of an app’s behavior, and file encryption protects data in certain scenarios (e.g. a lost device). The developer is still responsible for ensuring that things like SSL/ TLS are in place to safeguard transactions though.
.
It’s a slightly unpopular opinion but, in some cases, it may be necessary to limit innovation to protect users’ information. As mentioned, mobile apps are one of the most secure ecosystems anybody can use (they usually connect directly to the developer, rendering threats like malicious ads moot) but a mobile banking app still shouldn’t try to do anything that the website version doesn’t; it’s confusing for customers and changing code unnecessarily can create new vulnerabilities.
.
.
Getting Feedback
At every stage, listen to the app’s users. It’s impossible for small developers to find every issue with a new piece of software – some might only emerge when the app is run on certain devices or in parallel with other apps – so don’t underestimate the bug-finding potential of tens or hundreds of users using a new app at once. Beta or even alpha tests with small groups of users can help iron out the worst problems before launch.
.
Finally, collect analytics, reviews, social media abuse, and anything else that gives a clue to usage patterns and user experience. People are far more likely to vent their rage at a bust security feature on Facebook or in a negative review on the Play Store than via an official bug-reporting email address buried deep in a website. Hearing nothing but silence from a customer base should be a frightening prospect for anybody developing for humans.
