Mobile App Security vs. Web App Security | How They Differ
Mobile Apps Are Different Than Web Apps; Mobile and Web App Security Must Be Different Too
From a security perspective, almost every company invests in technology to protect their organization’s network, resources, websites and data. Even given the fast-expanding attack surface that mobile, IoT and other technologies are driving, many enterprises are making progress in securing those assets against attacks too. But do enterprises ever actually create attack surfaces?
The answer is, yes. That is precisely what happens when enterprises develop mobile apps. Businesses that are producing mobile apps for customers to download and use are effectively sending little digital time bombs to tick away on their customers’ devices. Because as useful – and even essential – as mobile apps are for today’s enterprise, the vast majority – for example, 92% of mobile banking apps, to cite just one industry – are riddled with vulnerabilities putting the enterprise and customers at risk.
Why the enterprise is putting customers (and itself) at digital risk
How did we get to a point where businesses in even security-conscious, highly regulated industries deliver mobile apps to customers incorporating significant risk? Bringing technology to customers is nothing new. For example, enterprises have had ecommerce sites with robust functionality for decades. And they have long since evolved capabilities to deliver web application experiences securely.
Here’s the problem: Mobile apps are not the same as web apps. By extension, mobile app security is not the same as web app security. And no matter how accomplished an enterprise has become at protecting its web-based apps, that knowledge is of little value in protecting mobile apps.
All too often, though, businesses are trying to shoehorn mobile app security into the development processes and solutions they have established for web apps. This effort may hurt more than it helps by bringing a false sense of security that the mobile apps can be treated the same. And it inevitably leads to the spectacular and costly mobile app security fails that make the headlines.
How the enterprise tries to secure apps
When I say shoehorn, what do I mean? Typically, businesses incorporate a variety of security measures depending on where they are in the software development lifecycle. While still in the development, and before you release your app, the goal is to scan the app for risks. This allows you to ensure, for example, that the app has not incorporated compromised third party code and does not create security, compliance or privacy risks. This function is provided by a solution such as zScan, a component of Zimperium MAPS.
To test how secure their app is once it is complete, one common option–required by regulatory bodies in some industries–is penetration testing, or pentesting. This entails subjecting your completed app to attacks as if the attacks were being conducted by a bad actor. That way, you can find any vulnerabilities a cybercriminal would find before they do, and correct them.
It is important to note that scanning your code in progress, and pentesting the final app, are both useful and can improve your app’s overall security; the ideal scenario is to employ both kinds of tests. But the problem arises when scanning and pentesting of mobile apps is based on solutions and processes designed for web apps.
Why web app security is different from mobile app security
As noted, businesses use a variety of solutions to help them create apps that are free of vulnerabilities. These solutions are well established and have been used for as part of developing web apps. But the vulnerabilities plaguing mobile apps are different from those affecting web apps.
For one, mobile apps can collect much more information about the user, such as location, biometric, video and audio data, than web browsers.
In addition, mobile apps are essentially public code. Web apps never release their code publicly, but anyone can download mobile apps from the public app stores and inspect the code using open source tools. This makes finding flaws in mobile apps easier.
Third, the most critical difference between mobile apps and web apps is where the apps run. Mobile app code runs on poorly protected end-user devices, where the users are the admins. They may have lax standards around applying updates or being selective in the apps they choose to download. Web app code, by contrast, runs on the enterprise’s server or cloud, over which the enterprise has complete control, and which reside well-protected behind corporate firewalls.
More broadly, this means mobile apps have a larger attack surface than web apps. The bad guys can not only attempt to compromise the app, its data stored and runtime memory, they can also attempt to compromise communications between the app and the enterprise’s back end, and target the data in the app, such as user names, passwords, and anything else stored locally. Such attacks can be far easier on mobile apps than on web apps, because the attacker owns the device and can manipulate the environment.
How to avoid sending digital time bombs to your customers
Knowing that mobile apps are alarmingly vulnerable, and that the tools and processes used to ensure security during web app development do not work the same way—if at all—for mobile app development, what can you do? Continuing the status quo—which means developing apps that are all but certain to put customers at risk—is not an option.
Instead, you can adopt a technology that not only allows you to identify security, privacy and compliance risks during app development but also monitors apps while they are in use on your customers’ mobile devices and actively protects your app on the device itself. This is what Zimperium MAPS does: it is a comprehensive solution that can help you protect your mobile apps throughout their life cycle.