11 Biggest Mobile Security Testing Mistakes That You Can Easily Avoid

Mobile security testing mistakes can be roughly divided into three types: those that are wickedly subtle and almost impossible to avoid; those that are avoided if you are a bit careful; and finally, those that can be avoided even by a novice. Unfortunately, the last category of mobile security testing mistakes is more common than should be. Anyway, our agenda here is not to make light of mobile app security landscape (which is terrible, by the way) but to highlight eleven very common and silly mobile security testing mistakes that can be avoided merely by maintaining a checklist and glancing at it every now and then.

Here are 11 Biggest Mobile Security Testing Mistakes that You can Easily Avoid

1. Controlled testing environment

Automated testing is called the holy grail of software development and for good reason. It saves time, gives you confidence in your code base, and allows new developers to rapidly get up to speed (by reading the tests rather than the docs). Unfortunately, this mindset doesn't translate fully into mobile testing. Mobile devices are highly personal, opinionated, restless creatures that break more rules than they follow. To be sure that your app works as expected, you need to step out of the emulator and out of the house. Use the app on low battery, while charging, while moving; push it into the background and see what it does; take up all the RAM and then fire your app; remove the SD card midway – all these are not signs of oncoming dementia but important testing scenarios for mobile devices. After all, isn't that how a mobile device gets used every day?

2. Trying to test for everything

It's a worthy ideal to chase 100% test coverage, but please understand that it's just not possible on mobile devices. There are too many shifting variables to interact with, and way too many things could go wrong to take into account. Instead, try to focus on the core functionality of your app and test it to the hilt. For everything else, relying on beta users and apologizing-and-fixing your way post the first release is the way to go.

3. Not testing the UI

Um, the UI tests? Yes, unless you want users to drop your app pronto. Granted, the user interface doesn't come to mind naturally when we talk of mobile security testing and performance testing. But realize that on mobile devices, the UI holds the greatest weight (if not the greatest). How the UI is communicating with the backend, and whether are (non-obvious) ways to divert or intercept the communication should be your top priority.

4. Testing too late

Testing early and testing often is both a tired maxim and a piece of impeccable advice. Too often, teams bolt on testing after the code base is finished. If a security vulnerability is discovered at this stage, the cost of fixing it can be enormous. It's better to know beforehand what your testing will focus on, and test proactively.

5. Ignoring common vulnerabilities

Some vulnerabilities are so common that we are likely to dismiss them as irrelevant or "this can never happen to me". Except that it happens, and more frequently at that. For instance, storing passwords or login data in a plain text file or storing access token insecurely is a sure road to getting toasted. And yet, can we be sure all the code we write is free of these?

6. Skipping testing on a real device

Sometimes your app can be so simple that you might think that emulator testing is sufficient. For instance, if all your app does is fetch listings from a website and update the ones favored by the user, it can be testing quickly and completely in the emulator. But we suggest not doing it. A real device is a can of worms that can expose your app in very unexpected ways (Tapjacking and Bluejacking come to mind). Therefore, always, always test on a real device, and if possible, test on multiple devices.

7. Not testing on all supported versions

Version fragmentation in Android breaks many a developer's backs, but there seems to be no choice at present. Unless you are developing for a single Android version, your security testing strategy must account for checking your app on all intermediary versions, especially the vulnerable ones. And even if you're developing for a single version, be aware that security settings can change within minor versions also (e.g., the SYSTEM_ALERT_WINDOW permission, whose default changed between Android 6.0 and 6.0.1).

8. Not performing static code analysis

Many security vulnerabilities are directly linked to, (to put it mildly) crappy coding. So while it's absolutely necessary and beneficial to do stress-testing and all that glam, scanning the code can ease a lot of pain. The best thing is, we now have great static code analyzers like Appknox available, which makes the task of checking code even during development brain-dead simple (Trust me you’ll look like a security pro). Don’t want grief? Then use a static analyzer on all of your apps!

9. Ignoring manual testing

The lure of the cloud has engulfed security testers also. The idea that your app is being stress-tested in the cloud by simulating thousands of devices instantly is both powerful and seductive. We aren't taking away anything from cloud-based testing of apps, but nothing can replace manual testing. Doing something unexpected and thinking of clever (or dumb) ways to use the app and break it down are invaluable. Never count out manual testing, and make sure a good chunk of your time and energy is reserved for it.

10. Aiming for as many devices as possible

Granted, you want to capture the largest possible market share out there. So you naturally feel like targeting every device on the planet. Our take? Don't. Unless you are a multi-million dollar company with plenty of resources to throw at a problem, you will do well to optimize your app to a selected set of devices. You will lose some potential market share, sure, but your users will be more loyal in the long run. And don't be scared of letting users know up front – display the supported devices in bold letters, and the users will thank you for not wasting their time.

11. Not having a testing strategy

Yup, strategies are boring, but they lead you to victory. Same goes for mobile security testing; there's so much to cover and so many things to do that it's easy to get overwhelmed and fall back to a hunt-and-peck technique. But that's no way to build high-quality, stable apps. As "enterprisey" as it may sound, a document laying down what you are testing in which phase and what your expected outcomes are will help you produce better apps and give you more confidence.

As we always say,  mobile security testing mistakes are avoidable (Just as long as you keep these points in mind) and mobile app security is a winnable battle. One part of that battle is common sense, and we hope this post on mobile security testing mistakes was able to impart some of it!