Seven Frequently Asked Questions About Mobile App Vulnerabilities
Mobile app developers have to release apps as quickly as possible. The time to market is so short that they often do not have time to check for security flaws.
Even when there is time, developers may not have the necessary resources to fix bugs.
That may be why, according to the 2016 NowSecure Mobile Security Report, business devices are times more likely to leak login credentials than other mobile devices. This brief article answers some of the frequently asked questions to start improving your app security.
1. What type of mobile app vulnerability is the highest risk?
The worst vulnerability is the one you don’t know about.
Next to that, however, lack of encryption in network communication is a serious issue. Clear text communication to network hosts exposes all data, including login credentials. Once that is exposed, everything else is exposed.
2. An app security consultant tested my new application and found no problems. What are the odds that a new app is flawless?
It’s probable the tester didn’t test hard enough or deeply enough. Maybe there’s nothing wrong with the source code, but login data is unencrypted, for example. It’s usually fairly easy to find a flaw that enables a bad actor.
Bottom line: keep testing for vulnerabilities. Automated tools are nice, but they can’t (yet) replace human searches for security weaknesses.
3. How do I choose the best security tools?
The first step is to ask colleagues and partners. See what people are talking about. Once you have a list, get trial licenses from multiple vendors. These are usually available for free or cheap. While you need to keep within your budget, you also need a tool that does more than simply tests the app’s function.
The best solutions will test source code, network communication, web access, forensics, and other areas. Consult with a person or company who has experience in dozens of security analysis tools to verify your app’s security.
4. What do you do if your third party mobile app developer doesn’t do its own testing and won’t share the source code with you?
Find a different third party app developer. If a vendor won’t do its own testing and won’t let you do the testing, that’s a red flag. It may not want to acknowledge security flaws so it doesn’t have to deal with them. Remember that a third party developer still has your name on it — not the developer’s — and you will be held accountable for problems.
5. Should my app developers go for security training?
Absolutely. Training is one of the core challenges of app security. Developers aren’t security experts and do not necessarily have the tools they need to make prevent app vulnerabilities from sneaking in. Learning about threat modeling, defining specific security requirements, and identifying how bad actors exploit vulnerabilities can help set them up for success.
OWASP (owasp.org) is probably the best developer training resource available today. YouTube also has a number of useful tutorials.
6. Should I do traditional app vulnerability testing or focus on source code analysis?
It’s important not to rely on a single angle. Different security analysis tools find different things. Source code analysis is a good start, but vulnerabilities often “live” elsewhere in the app. It’s best to look at the application from every possible perspective.
If budget is a consideration, consider staggering vulnerability testing. For example, you may analyze source code one quarter and review the app itself in the next.
7. What are some hard numbers I should measure to test the security of my application?
In general, you should measure vulnerabilities as you uncover them. They may be classified into one of several categories. These will tell you what aspects of your application are at the most risk from bad actors and other weaknesses. One list of these categories includes:
- Initial vulnerabilities
- Repeat vulnerabilities
- Remediation latency
- Exploitable vulnerabilities
- Vulnerabilities that go against best practices
- Vulnerabilities that are being sought after (based on your log files)
