The average consumer spends nearly three hours a day on mobile devices, with 86% of that time devoted to mobile apps. This provides plenty of opportunities for security threats to attack consumers’ identities, bank accounts, and privacy. Yet less than half of app development companies security test each app they build, and 33% never test any apps at all.
Mobile app security is at an all-time low just as more consumers than ever are using mobile apps. With 40% of American employees using their own mobile devices for work, unsecured apps are a significant threat to businesses and the economy.
Some app developers have taken a lackadaisical approach to security because they believe they won’t suffer if their customers’ apps are insecure. But when your apps are insecure, so too is your business. A company that develops a reputation for insecure apps is a company on the verge of collapse.
While a user might purchase an unsecured app once, a bad experience with your business is likely to permanently turn them away. You already know that you need to secure your apps, but the steps you’ve taken to ensure security might not be as effective as you hope. Secure your mobile app by ensuring you don’t make these mistakes.
Inadequate Security Testing
More than 96% of the top free games on Google Play can be reverse engineered, and 85% can be decompiled. One of the simplest ways to prevent your app from joining the ranks of these insecure programs is to perform security testing at every stage of development — not just immediately before releasing your app.
To optimize security, you need to use both dynamic and static source code analysis. Otherwise malicious attacks could reverse engineer or modify your app’s code.
Unencrypted Data Storage
When unencrypted data is stored directly on a device, it’s more vulnerable to attacks. And if a user’s device gets hacked, virtually anyone can access the data your app has stored on it. Depending upon the specifics of your app, this could expose not only an individual user to security issues, but other app users, too. If your app must store some critical data on a user’s device, that data should be encrypted in addition to sufficient app security.
Most developers know that encryption greatly increases app security, yet many fail to use it. Among those who do, encryption techniques are often weak or obsolete. If your app requires customers to provide any type of sensitive data, such as credit card numbers, health information, or even mailing addresses, ensure you use updated encryption.
No Binary Protection
Though binary protection is a fundamental component of sound app security, 97% of mobile apps don’t use it. Though health and finance applications house some of consumers’ most sensitive data, 90% of these apps — including those sponsored by government agencies — lack adequate binary protection. This allows malicious users to reverse-engineer your app, steal consumer data, and alter application code.
Code Security Issues
It may be tempting to use sections of code written by other developers, but some hackers make malicious code readily available in the hopes that lazy developers will use it in their apps. You don’t have to write the code for an app from the ground up. But if you use code from other developers, research your sources and check the code line for red flags.
Data Caching Vulnerabilities
Data caching on mobile devices makes these devices faster. It also renders them more vulnerable to security breaches from hackers who access the cache. Requiring a password to use your app is the simplest way to circumvent this problem.
Unfortunately, many users hate entering a password, and some will even refuse to use an app that requires it. If user feedback indicates that passwords are a no-go, try setting your app to automatically clear the cache each time the device reboots. Note, however, that this approach is still less secure than requiring a password.
Inadequate Security Updates
Mobile apps exist in a constantly evolving environment, with new and challenging security threats arising on a near-continual basis. You cannot code your app, release it, and then hope for the best. You must adapt to the results of routine security testing by providing patches for new and developing security risks.
Of course, developing a patch is only half the battle. You need to also get your users to install the security fix. Make your patches easy to download and install, and provide clear information about what each patch does.
Don’t make unnecessary alterations to the program with each patch either, since consumers who hate a minor change might not install subsequent updates if they worry those updates will do more than just improve security. For instance, it’s a bad idea to change the interface or remove some options unless absolutely necessary.