In the mobile app development world, it’s common knowledge that consumers care far more about app functionality than they do security, that their biggest fears are having their private information stolen from the cloud, and that consumers are largely fine with a “buyer beware” approach to security.
Unfortunately, all of these beliefs are wrong. A recent Appdome survey of 10,000 mobile consumers from around the world found that, contrary to conventional wisdom, they value security and have a sophisticated understanding of the mobile security landscape. They expect to be protected. If an app were breached or hacked, 74% of all consumers would stop using it, and 46% of all consumers would tell their friends to stop doing so.
This is a strong endorsement from consumers of the message CISOs and security teams have been expressing for years: mobile apps need strong security. Clearly, given the data that Appdome gathered, consumers will reward apps that demonstrate they provide strong protection. It’s a significant, potential competitive differentiator. But implementing strong security into mobile apps is easier said than done. The relentless pace of mobile app development, the need to keep costs under control and the shortage of skilled iOS and Android security experts all conspire to make implementing security all but impossible.
In this article, we’ll first go through the various myths about consumers and mobile app security that the Appdome survey debunked. Then, we’ll examine the challenges of implementing mobile app security and how development teams can overcome them.
Debunking the myths
Let’s take the top myths one-by-one.
Myth #1: Consumers are comfortable with “buyer beware” mobile app security strategies.
In fact, consumers expect app publishers to provide a very high level of mobile app security and protection. The survey found that nearly three-quarters (73%) of all consumers would stop using a mobile app if they knew it left them unprotected against attack. A similar percentage (74%) would stop using a mobile app if their app was breach or hacked. And nearly half (46%) would tell their friends to stop using an app if their app was breach or hacked.
Far from being comfortable with “buyer beware,” consumers have participated in this kind of market because they had no other choice. Barring a public breach, there’s really no way currently for consumers to tell the difference. That said, if they were made aware of security weaknesses, it’s clear they would gravitate towards apps that provide strong protection.
Myth #2: Consumers are willing to give up security to get better features in a mobile app.
Actually, most consumers value security and malware protection as much or more than they do features, with almost two-thirds (63%) saying that they value security as much or more than they do features in a mobile app. Again, the data show that were consumers educated about which mobile apps provide the protection they desire, they would choose to use those apps.
Myth #3: Protecting against network and cloud breaches should be #1 priority.
Consumers care most about app-level, on-device threats and largely dismiss network-cloud threats. More than six in 10 (62%) of all consumers fear someone hacking their app, making it the No. 1 mobile app threat, and more than half (56%) fear malware threats on their device, making it No. 2. Network and cloud threats rank No. 7 with less than one third (32%) listing it as a concern.
The takeaway from these findings is that publishers need to redouble their security efforts at the app-level — securing the cloud and the network is not enough to satisfy consumers.
Myth #4: Mobile app security is only relevant if the mobile app is in a regulated industry.
Consumers demand the highest mobile app security from all kinds of apps equally. For instance:
36% of all consumers expect mobile banking apps to the highest level of security
33% of all consumers say that “all transaction apps” should have the highest level of security
16% of all consumers say that ewallet/payment apps should have the highest level of security
12% of all consumers say that retail and food delivery apps should have the highest level of security
Certainly, financial apps handle very sensitive data, and if there were a breach, a consumer’s bank accounts could be compromised, so it’s not surprising that these apps are their top concern. But their concerns for mobile app security clearly doesn’t stop with banking and payments. All app makers need to strengthen security.
Challenges to security implementation
My company regularly analyzes mobile applications from Fortune 500 companies to assess their security weaknesses, and, pretty much without exception, we find that these apps can typically be compromised within 15 minutes. Simply put, they lack basic security best-practices.
The state of mobile app security is still not strong. According to The Verizon Mobile Security Index 2021, 76% of respondents said they’d caved in to pressure and sacrificed mobile security in some way. It’s not that publishers aren’t incorporating any security measures into their apps. It’s just that they are frequently so poorly implemented that they are easy to circumvent.
Here are the biggest security weaknesses we encounter:
Insufficient encryption and lack of data protection
Often, encryption is usually not applied consistently or comprehensively, leaving sensitive data exposed. It’s common to find secrets stored hard-coded in an app or as plain-text strings that hackers can easily find.
A mobile session can be compromised in many different ways. Sometimes apps contain poorly implemented APIs that expose more information than is necessary in API calls. Others fail to inspect certificates offered by a server, or do so in a way so that certificates can be easily forged, swapped or otherwise manipulated. The end result is that data travelling from the app to external services is vulnerable to hackers.
Failure to prevent reverse engineering and tampering
Most mobile apps lack obfuscation and strong app shielding, both of which are required to protect an app and source code against malicious reverse engineering and tampering.
It’s easy for hackers to reverse engineer source code unless it’s properly protected. The information that they gather from doing so enables them to:
Use disassembler to analyze code and modify an application’s values stored in memory
Search for strings in the source code to locate sensitive user data stored in the clear
Understand the application logic to find vulnerabilities for future attacks and manipulate key functions, such as the purchasing process
Create Trojans that look and feel like the genuine app but actually have a malicious purpose
Lack of jailbreak/rooting prevention
Jailbreaking (iOS) and rooting (Android) are both forms of privilege escalation that hackers use to attack mobile apps and mobile users by compromising the security of the app’s environment. By gaining administrative access to a mobile operating system and file system, hackers can attack mobile apps more easily.
For example, they can bypass or disable an application’s existing defenses, modify signals going to or from an app, change the execution path of code, and even remove code or replace it with their own malicious implementation.
Lack of Protection Against Dynamic Instrumentation and Code Injection
Dynamic instrumentation frameworks can be abused to hook into apps, discover running processes, modify an application’s code or memory during runtime, and change an app’s behavior. As a result, hackers can take over accounts, compromise e-commerce sites and infiltrate a mobile app’s backend.
DevOps and the mobile app security challenge
For strong security, mobile apps need a multi-layered defense that, at minimum, includes app shielding, anti-tampering, code obfuscation, data encryption, jailbreak/rooting prevention, and man-in-the-middle prevention. And while there are commercial SDKs and third-party libraries available for these functions, these approaches require a great deal of time, money and skill to implement.
For example, let’s say we want to implement data encryption using an SDK. We need to take into account data structure dependencies, because different data types have varying sensitivities to latency, and also consider the media and method of data storage, because that will also constrain choices for the encryption model. The programming language you use will also be a factor, because different SDK cryptokits may not work with your language of choice.
Finally, there’s key management. How do you derive the keys, what key strength should you use, and most importantly where do you store the encryption keys?
It’s complex, and that’s just the choices that go into encryption. You’ll need SDKs for additional security layers, and each SDK will introduce its own framework and programming language dependencies, which may conflict with one another.
Traditional mobile app security does not fit DevSecOps
The root of the mobile app security problem rests in the way in which mobile apps are developed, released, and updated in a modern agile organization. Dev and Ops operate in a world where everything is dynamic and automated. The traditional world of mobile app security is the opposite – static (set and forget), manual (line by line coding), monolithic. A manual monolithic process will never fit into an agile delivery model no matter how to try to slice it.
The true promise of DevSecOps is about built-in Rapid Mobile App Security (RMAS), delivered as a fundamental part of an agile release process, where security is designed into the process at each and every phase of the life cycle, and where security features or the security model can be delivered and evolved atomically, iteratively and dynamically – in a way that fits the specific and unique characteristics of the app itself. In other words, the security model adapts to fit the app (not the other way around).
The way forward for mobile app security is automation, which is what made DevOps possible in the first place. By applying AI and ML, the industry can create automated security implementations that will truly enable DevSecOps. This will allow developers, ops and security professionals to deliver secure apps on time within an agile, fast moving and iterative app lifecycle and release process. It’s the only way publishers will be able to meet consumers’ high expectations for mobile app security.