NowSecure Connect — THE mobile AppSec + AppDev community online event — returns with new content and the latest training. Join the world’s brightest innovators, practitioners, community leaders, and industry influencers online for in-depth training, discussions, strategy sessions, CTF and more. Gain access to keynotes, exclusive breakouts, expert panels, on-demand sessions, plus an interactive peer-to-peer community. #NSConnect22 is your source for cutting-edge mobile AppDev, mobile AppSec and mobile DevSecOps insight. Register for replays!

magnifying glass icon

Ignore these common mobile app security risks at your own peril

Posted by

Kevin Beaver

Information security consultant at Principle Logic
Kevin Beaver, CISSP is an information security consultant, writer, and professional speaker with Atlanta, GA-based Principle Logic, LLC with over 28 years of experience in IT and 22 years in information security. He specializes in performing independent security assessments, with a focus on application and IoT testing, to help organizations minimize their IT risks, take the pain out of compliance, and uncheck the checkboxes that keep creating a false sense of security. Kevin has written/co-written 12 books on information security including the best-selling "Hacking For Dummies" and "The Practical Guide to HIPAA Privacy and Security Compliance." Kevin has also written over 1,000 articles on information security and serves as a regular contributor to websites such as TechTarget's, Ziff Davis', and IBM's In his free time Kevin races cars in the SCCA Spec Miata class.
Ignore common mobile app security risks at your own peril

After performing independent security assessments for more than two decades, I’ve heard just about every excuse for why a particular IT asset doesn’t need an assessment. People usually base the excuses on an assumption such as, “The application isn’t critical because it doesn’t process or store sensitive information.” When it comes to mobile apps, don’t jump to that conclusion too quickly. The mobile apps used by your customers, workforce, and partners generate, store, and transmit personal and sensitive information in ways that aren’t always obvious. You need to test any assumptions you make about the security of a mobile app from an attacker’s perspective to eliminate a number of common mobile app security risks.

Mobile apps have replaced traditional client/server models, and now people spend more time using mobile apps and devices (51 percent of time) than desktop or laptop computers (42 percent of time) or other connected devices (7 percent of the time). Mobile app workflows are complex, and the data they handle  is sensitive. The risks are high –  arguably higher than in any other application medium given that mobile devices are easily lost or stolen. Furthermore, because mobile systems are often not locked down in the same ways as traditional organization workstations, they’re even more susceptible to abuse. It’s the perfect storm of BYOD, shadow IT, and lack of visibility into the network/application environment that’s creating considerable organization risk.

Common mobile app security risks

I come across a lot of security vulnerabilities when I perform assessments of mobile apps. Some, like the following, tend to be predictable, and thus, should be on your radar.

Network communication sessions that are unencrypted or are running via SSL and encryption ciphers that are known to be at risk: Sensitive data traveling over a mobile carrier’s network, Wi-Fi, and the Internet is at risk of being exposed. For example, a malicious individual may intercept mobile data by eavesdropping on Wi-Fi traffic. To mitigate against this risk, make sure all connections between your app and other services are properly encrypted. That includes using SSL/TLS, making sure that the app only accepts valid certificates that use a strong cipher, not accepting self-signed certificates, and in many cases implementing certificate pinning.

Weak password requirements and enforcement, lack of user session timeouts, and lockout after a certain number of failed login attempts: If user authentication mechanisms within the mobile app are weak or non-existent, a malicious individual can spoof authentication to the app’s backend without needing to manipulate the app itself. Weak authentication can expose your users and increase the risk of fraudulent transactions.

In a draft of its digital identity guidelines, the National Institute of Standards and Technology (NIST) recommends that passwords be at least eight characters in length and encourages allowing users to create passwords as long as they like. Depending on the sensitivity of the actions that users can perform using your mobile app, consider implementing two-factor authentication as well.

Finally, to prevent against unauthorized access to app data in the case of a lost or stolen device:

  • Lock an account out after a certain number of failed log-in attempts to prevent brute force attacks
  • Terminate active app sessions after a period of non-use and require the user to log back in

Poor input validation that allows for users (and attackers) to inject legitimate commands and random junk into input fields: A malicious actor can exploit a lack of, or poor, input validation to execute SQL injection, command injection, and other attacks. You can prevent these kind of attacks on your mobile app’s backend by validating input from the app and user before transmission from client to host and during receipt.

Sensitive artifacts such as login credentials stored in unsafe ways, that are never cleaned up and left vulnerable: It’s best to assume that any data your app writes to a device is recoverable. So, unless it’s absolutely necessary, simply avoid storing or caching data. Also, be sure to check whether your app is storing data in places you don’t realize such as log and debug files, cookies, web history, web cache, property lists, SQLite databases, and elsewhere. For the most part, you need to know what data your app is storing, whether storing that data is necessary (if not, stop storing it), and that any data you absolutely must store is stored securely.

Modeling mobile app security threats

Even when sensitive information, per se, is not processed or stored by these mobile apps, there’s still the risk of users re-using credentials which increases the risk  of unauthorized access or exposure of other systems. At a  higher level, metadata generated, stored or transmitted by a mobile device or app can provide an attacker with reconnaissance that leads to other certain organization systems and third-party relationships that can be further exploited.

The threat scenarios are endless. In addition, you also need to consider the risks of damage to your brand and reputation (and other intangibles) should your mobile app fall victim to an attack as a result of one of these types of flaws.

When assessing the security of a mobile app, source code analysis can help (and I always advise it). Notice that none of the weaknesses listed above are particularly sneaky or hard to find. Just take a look at any number of “low-hanging-fruit-type” examples of security vulnerabilities that I’ve written about in the past. Many of the vulnerabilities listed above only come to light as a result of examining the app’s behavior during runtime. A comprehensive assessment of a mobile app’s security must include both static analysis (evaluating code in a non-runtime environment) and dynamic analysis (analyzing the app as it operates during runtime).

What causes these common mobile app security weaknesses?

From my experience, these weaknesses are usually introduced into the mobile app’s genetics and implementation through poor requirements definitions, weak threat modeling, and no ongoing security testing. No organization, regardless of its size, industry, or level of security maturity is immune to these mobile app flaws.

Remember, you need to test your assumptions. Don’t assume that someone else is going to take care of these security issues. And don’t ignore these common mobile app security risks simply because people aren’t asking about them or addressing them isn’t required by contracts or regulations. The risks are there. It’s just a matter of time before they’re brought to the surface. You’ll want to  make sure you find them before someone else does.