When mobile first emerged on the scene, it was something of a new frontier for application developers. Thanks to location features, Bluetooth and a variety of other unique user interface components, developers had just as many challenges to overcome as they did opportunities to make unique, innovative mobile solutions.
One of the critical components of mobile software development that needed to be addressed was security. Mobile devices are subject to a special set of cyber threats and exploits that traditional computers might not be. As such, security testing is a hugely important facet of mobile application development. While solutions for mobile devices have certainly come a long way in the past five years or so, many QA teams may still be operating on the basis of misleading myths when it comes to mobile security testing. Here are three of them:
Myth 1: Security Testing Takes a Backseat to User Experience
In theory, when developing business applications for internal corporate use, client communications and data sharing, UX is very important. For example, if navigation and feature access within the application are cumbersome, a business runs the risk of shadow IT - users may flock to alternative applications that put data at risk.
Nevertheless, the idea that UX testing is, therefore, more important than security testing is entirely false, and developers operating under that impression will be doing themselves, and their end users, a big disservice. A mobile application must still be secure by design, and the only way to vet integral security features is with thorough, smart test management. At the end of the day, the application is still running on a user's mobile device, and in many cases, is directly interacting with sensitive personal or company data.
According to software development expert Manish Mathuria, mobile app security testing is vital since mobile devices introduce a variety of new threat vectors that simply did not issue on traditional computers. Furthermore, because mobile devices are relatively young and evolving at such an alarming pace, scripting strong, reliable code can be a huge challenge.
"Most brands have apps that do something significant with the end users' mobile device. This device stores all kinds of data - their personal information, their contacts, their calendars, things like that. So the companies and enterprises building mobile apps are definitely concerned about security from multiple sides." - Manish Mathuria
For this reason, privacy, user verification and authentication must all be extremely well tested. UX is important, but nothing will turn a user off more than an application that cannot keep his or her data safe. Security testing must be addressed with the same sense of order and rigor that any other test management strategy would.
Myth 2: Mobile Security Testing Cannot be Automated
This couldn't be farther from the truth. In fact, because mobile code is relatively new, hackers are still in the process of getting up to speed when it comes to cracking mobile devices. This is not to undermine the extent to which mobile devices are vulnerable, but rather, to point out that many of the most threatening cases of mobile malware have already been identified, and must, therefore, be addressed during the mobile testing life cycle.
All mobile devices will have to run static test cases to ensure that they are steeled against known mobile exploits, and this process is ideal for test automation. TechTarget contributor Michael Cobb refers to static testing as a sort of audit or review that can help test for security flaws and also ensure that an application cooperates with certain compliance codes such as HIPAA or PCI. Furthermore, Cobb notes that in static tests, it's easier for testers to see exactly how data flows through an application - nothing is hidden.
It is true that dynamic security tests are especially important when it comes to mobile devices, and that many of these must be run manually. Penetration tests and other black box testing, for instance, may be required for mobile apps with more stringent security requirements. Nevertheless, automation still has a very important role in a mobile test management strategy.
Myth 3: When it Comes to Mobile, Testing Needs to Happen All At Once
Do not misconstrue the concept of static testing. It doesn't mean that testing happens all at once, and only once. Yes, static testing does typically occur in the implementation phase rather than when the application is running. Nevertheless, as new vulnerabilities are discovered, and as changes are made to a mobile application, test cases will have to be revisited - think of it as regression tests for security QA purposes. Even static tests aren't totally static, and they never will be. The functionality of applications is always changing, and modern hackers are especially adroit at exploiting the untested cutting edge of software. They often find holes in places that even the most experienced testers and developers wouldn't think to look.
The beauty of working with a reliable test management tool is that test cases can be saved and recycled, which means that as new exploits are identified, even static security tests are run again to make sure nothing else has been affected in the process of patching one security flaw. Meanwhile, test cases for the newest security patches can be created, automated and saved for future use on new iterations or other software projects.
In this sense, mobile security testing - to a certain degree - is an agile process. It's more than likely that the number of software updates that address new security concerns will continue to rise. Ensuring that mobile software is as secure as it is functional will continue to be a top priority as this happens.