When talking with customers, I often hear the same misperceptions/myths about mobile application security testing. They range from the idea that mobile apps are safe because Apple and Google test them to the notion that testing mobile apps is the same as testing web apps.
These myths leave organizations in a dangerous position because they both use and publish mobile apps that are inherently insecure, putting their customers, employees and organizationes at risk. As you probably know, there’s been no shortage of mobile app data breaches – from Air Canada (20,000 users), to Under Armour MyFitnessPal (150 million users) and British Airways (380,000 card payments).
As a service to any company that’s creating or using mobile apps, I’d like to clear up three of the most common myths about mobile app security testing.
Myth 1: “Static source code testing is sufficient for mobile”
I want to dispel once and for all the notion that static source code scanning (SAST) is good enough for testing mobile apps. The industry is fairly saturated with source code scanning tools that date back to pre-mobile days. Yes, these tools can find vulnerabilities, but well over half of the real-world issues we routinely see in mobile apps would not be found by static tools —- they require dynamic testing.
Mobile apps are typically a composite of developer code, licensed and downloaded third-party libraries. They require the developer to establish connections with multiple backends which can be difficult to secure properly and run on a full mobile operating system and device that can provide a launchpad for attackers. Many apps download files at run time, add additional code on the fly and/or use third-party libraries — none of which gets tested properly by SAST.
SAST testing misses two large chunks of the mobile attack surface — data at rest and data in motion. For instance, it doesn’t flag storage issues such as data caching, decrypted keychain, data stored in log files or on SD cards, or passwords being accessible. Nor does it assess for vulnerabilities that occur when data is in transit, such as rogue access points, session hijacking, fake TLS certificates and improper TLS validation.
To properly test a mobile app, you have to load it on a device to get real-world test experience – that’s dynamic testing. Only then can you get an accurate view of how the app really functions. Combine the results of static and dynamic testing to dramatically improve your results and reduce false positives.
Myth 2: “Testing mobile apps is the same as testing web apps”
Another common misconception I hear is that the same tools and techniques used to security and privacy test web apps can apply to mobile app. Web app security testing typically spans the web app code and the handful of APIs they call, typically using SAST tools.
Mobile apps are inherently different from web apps. With web apps, the browser is isolated from the client machine, all the application code sits behind a firewall on a server, and the browser handles secure communications. With mobile apps, you have a full device operating system sitting underneath the app that can interact with other apps, some of which may be malicious. There’s a lot going on in memory on the device itself. All this makes mobile apps significantly more complex to test than web apps. You have to look at data at rest as it interacts with the device and look carefully at data in motion as it is transferred over the network. Doing it well requires a security testing tool specifically designed for mobile applications.
Myth 3: “Mobile apps are secure because Apple and Google test them”
Finally, there’s the myth that Apple and Google deeply security test all apps before they put them in their app stores. In reality, they focus on enabling an ecosystem of mobile apps.
Apple and Google provide a framework and tools to help developers build secure apps. They will check for compliance with their guidelines and APIs, as well as for malware and static vulnerabilities. But they don’t check for things like data leakage, privacy issues or vulnerabilities in third-party libraries that an app uses, nor the actual app functionality and dynamic code. In fact, both Apple and Google are quite clear that developers are responsible for making sure their code is secure.
Our data shows that the vast majority of mobile apps on both Android and iOS have some type of vulnerability or data leakage. So clearly everyone needs to improve the development and testing processes.
Truth: It is possible to automate mobile app security testing
The good news is that security testing mobile apps doesn’t have to be burdensome. With an automated security testing tool like the solution provided by NowSecure, you can integrate security testing into the app development process.
Our security testing platform runs automatically for developers and security teams, testing each build each day. In mere minutes, NowSecure software tests their code on actual mobile devices and deliver results showing vulnerabilities and privacy issues along with details about how to fix them. Save time and money by fixing an issue at the dev stage vs. when the app is in production and suffers a breach. That’s the power of DevSecOps.
These are just a few of the myths surrounding mobile app security. To dive deeper into them and learn about others, check out the recent webinar, “Debunking the Top 5 Myths About Mobile AppSec.” I presented with our Chief Mobility Officer Brian Reed. It’s full of facts and figures that’ll enlighten you to the importance and benefits of using an automated mobile application security testing tool to ensure you’re releasing only vulnerability-free mobile code into the wild.
