The OWASP Top 10 Mobile provides an overview of the critical security risks mobile app providers should keep an eye on.

Nowadays, nobody needs to explain how important mobile apps are for any business. What’s more, with the number of connected devices in the world growing practically by the minute, mobile IoT apps have an important role to play.

With such widespread use, mobile apps are very susceptible to security breaches, and ignoring the security aspect of a digital product and hoping for the best is no longer a viable strategy. In the evolving digital world, safeguarding one’s business interests and maintaining customer trust is crucial for staying competitive. 

Our experiment demonstrated that even OWASP-guided prompts leave exploitable gaps when the underlying code is AI-generated — the standard was applied, but system-level assumptions weren’t.

To concentrate their cybersecurity efforts, companies should first be aware of the challenges and the risks that lurk in the digital space, and the OWASP Top 10 Mobile list is the first step in the right direction.

How OWASP Top 10 mobile risks help companies secure their digital assets

Mobile app security is not just about protecting technical assets. Fundamentally, it is about safeguarding a company’s reputation and customer data and possibly avoiding legal repercussions. Data breaches exposing sensitive user information or a company’s intellectual property not only result in financial losses, but severely damage customer trust. 

With that in mind, it is very important that we have and nurture communities of security experts who will look into the common issues one might run into in the digital world. The OWASP Foundation is one of those communities. Through freely available resources like articles, methodologies, community-led projects, and conferences, the foundation actively works on enhancing digital security. 

To help you digest the biggest mobile dangers of today, we provide a simplified overview of OWASP’s risks and their implications for businesses.

OWASP Top 10 Mobile ranking overview

The OWASP Top 10 mobile risks list presents a refined perspective on the evolving landscape of mobile security threats. Each entry on the list is focused on a specific area of concern, emphasizing the importance of a proactive security mindset. 

However, security breaches in real life typically don’t happen on account of a company’s susceptibility to a single risk from OWASP’s list. Often, attackers will exploit multiple weaknesses and leverage social engineering attacks to reach their malicious goals. The examples we provide indicate that a specific risk was acted upon, but we should note that interpretations may vary and that often, only the affected company knows the true cause of a breach.

M1: Improper credential usage

A new entry on the OWASP list, improper credential usage is such a critical issue that it immediately earned the status of the number one security risk for this year. Hardcoded or poorly managed credentials that are not encrypted are very common and very easy to take advantage of. 

A famous example of this type of exploit happened to Uber in 2017 when the company reported that the personal information of 57 million users and 600,000 drivers was exposed because hackers discovered a hardcoded Amazon S3 Datastore key in a private GitHub repository used by Uber developers. 

Dangers

By gaining unauthorized access to a person’s credentials (i.e. mobile banking PINs, Token OTPs, email passwords, etc.), malicious actors can employ automated attacks or other methods that result in data breaches, privacy loss, and various fraudulent activities. Businesses face severe repercussions, such as reputation damage, fraud, information theft, and unauthorized access to data. 

Mitigation strategies

Avoiding hardcoded credentials in the app source or any configuration file, encrypting data transmission, and handling storage securely, together with regular updates of API keys and tokens. There are plenty of static and dynamic code analysis tools for mobile platforms that can help you detect some of the issues.

It is also very important to employ strong authentication protocols to protect against unauthorized access and ensure data integrity. If you want to look into this further, OWASP has a cheat sheet on how to implement proper authentication, including different protocols.

M2: Inadequate supply chain security

Another new entry on the list and also a very common issue is inadequate supply chain security. According to OWASP, supply chain security refers to the entire ecosystem used for developing and distributing mobile apps. This includes third-party libraries, SDKs, vendors, and processes like coding, testing, and distributing. 

Failing to implement security measures throughout the process and in some of the mentioned components, we can easily risk serious vulnerabilities in mobile applications, allowing attackers to insert malicious code or exploit third-party libraries. For example, this happened with the EventBot malware discovered in 2020. The malware bypassed security measures by exploiting third-party libraries and SDKs within Android apps to steal user data and financial information.

Dangers

These kinds of attacks can potentially lead to data breaches, malware infections, and in some cases, complete control of the device. Businesses may face financial losses, reputational damage, legal consequences, and interruptions in the delivery of goods or services. 

Mitigation strategies

To prevent such scenarios, it’s crucial to implement secure coding practices and conduct thorough testing and code reviews. Also, when picking third-party libraries and components, focus on the community around it, the proactiveness of the maintainers, and the quality of the support. Employing all of this will form a certain level of protection that is crucial in battling this risk.

Keeping your dependencies up to date is also a must, or even better, automating the update process with the available tools. Last but not least, establish robust and secure app signing processes that protect your app signing keys and certificates.

M3: Insecure authentication/authorization

What used to be two separate entries on the list is now one merged entry that is higher on the security risk ranking. Insecure authentication and authorization expose mobile applications to unauthorized access and data breaches. 

Dangers

Attackers can exploit these vulnerabilities to perform actions posing as legitimate users or access sensitive data. This can seriously impact a business’s reputation, leading to information theft and financial losses. From a technical perspective, in worst-case scenarios, this can also lead to destroying an entire system. 

This is one of the most consistent findings in AI-generated code. Our vibe-coded application security experiment found role-assignment vulnerabilities in every app tested, with no explicit security guidance.

Mitigation strategies

Prevention includes avoiding weak authentication patterns, avoiding offline authentication, and relying on server-side security. Integrating robust authentication mechanisms like multi-factor authentication to ensure data integrity and protect sensitive user information is also a must. In some cases, improper usage of features like biometric authentication can also make for insecure authentication.

M4: Insufficient Input/Output Validation

Another new entry on the list, insufficient input/output validation occurs when an app fails to properly validate data from untrusted sources, leading to the execution of malicious input. This common risk in mobile apps can lead to severe security issues, such as data breaches, SQL and command injection attacks, and unauthorized data manipulation. 

Dangers

Exploiting these risks can severely impact an organization’s reputation through data breaches and system failures, eating away at customer trust. It can also lead to legal issues and financial penalties for not adhering to data protection laws.

Mitigation strategies

The necessary thing to do is implement the required validation on both the client and the server side, employing whitelisting approaches and sanitizing data to prevent the execution of harmful input. Also, it’s important to conduct regular security assessments like code reviews and penetration tests.

M5: Insecure Communication

This is one of the rare entries ranked lower than in the last year’s release. This is a good sign because it means that the risk is being addressed to some capacity. Nonetheless, insecure communication remains a serious issue. It poses a risk by allowing attackers to intercept or alter data transmitted by mobile applications.

Dangers

Exploiting insecure communication and leaking sensitive data can result in a privacy violation, which compromises the user’s confidentiality and has legal repercussions for businesses.

Mitigation strategies

Implementing end-to-end encryption, using secure protocols like TLS, and regularly updating security certificates are effective strategies. The OWASP web page provides a short list of very concrete best practices for iOS and Android that you can follow to make your app more secure.

If you are interested in a more technical approach, you can check out our article on preparing your Android app networking for a penetration test or the one about SSL pinning on iOS.

M6: Inadequate Privacy Controls

Inadequate privacy controls are another new addition to OWASP’s list of mobile risks to keep an eye on. Privacy controls protect Personally Identifiable Information (PII) such as names, addresses, financial data, and sensitive personal details from unauthorized access.

Dangers

Attackers target this information to commit fraud, steal funds, blackmail, or damage critical data. All of this can have a negative impact on user trust and potentially result in regulatory fines, which depend on the number of affected users. The technical impact of this risk is low but not ignorable. 

Mitigation strategies

Businesses can mitigate this risk by implementing robust data access controls, conducting regular privacy assessments, and ensuring compliance with privacy laws and regulations.

M7: Insufficient Binary Protection

Previous entries known as M8: Code Tampering and M9: Reverse Engineering are now one combined entry. We can see that the risk itself moved up in the ranking, which makes it even more important to be aware of. 

Insufficient binary protection makes mobile applications vulnerable to reverse engineering and tampering. While somewhat similar, there are important differences between the two. Reverse engineering involves analyzing a system to understand its operation without accessing its documentation or designs. Tampering, on the other hand, refers to unauthorized alterations or manipulations of a system or software to change its behavior or outcomes. Both can lead to intellectual property theft and compromise app integrity.

Dangers

What makes these kinds of exploits dangerous is the fact that attackers may alter app binaries to unlock paid features or simply evade security layers in specific parts of the application. Businesses face significant risk if intellectual property, such as algorithms or AI models, is leaked or stolen by competitors. It is also important to note that all apps are vulnerable to binary attacks.

Mitigation strategies

Protection involves using code obfuscation techniques, implementing tamper-detection mechanisms and root detection, and securing application code against unauthorized modifications. Some useful libraries and tools that can help with this are Google Play Integrity API for Android and the detailed OWASP documentation for iOS.

M8: Security Misconfiguration

Previously known as M10: Extraneous Functionality, this entry has jumped from number ten to number eight in the risks list. While perhaps it is not so easy to exploit, it is a risk we should nonetheless be aware of, especially considering the move in its ranking.

To illustrate, in 2022 Microsoft discovered a high-severity vulnerability in the TikTok Android application, which could have allowed attackers to compromise user accounts with a single click. Luckily, TikTok responded promptly to Microsoft’s notification by releasing a fix. This example shows how improper security configuration (M8) (in this case, of Android’s WebView) and DeepLink validation (M4) can cause significant harm in the authentication/authorization flow (M3).

Dangers

Security misconfiguration can expose mobile apps to various attacks, leading to unauthorized access and data breaches. This can also cause some application downtime and disrupt a business, which can have a negative effect on the finances and cause brand damage.

Mitigation strategies

Regular security audits, adherence to secure coding practices, and ensuring proper configuration of security settings can help mitigate these risks. A common pitfall is failing to review default configurations of tools and frameworks.

M9: Insecure Data Storage

This entry demonstrates some general improvement in app development, as it dropped from number two to number nine. However, insecure data storage practices can still bring forth significant security risks. For example, this happened to UnderArmour’s MyFitnessPal app in 2018. The breach involved unauthorized access due to insecure data storage and affected 150 million users, exposing their usernames, email addresses, and hashed passwords. 

Dangers

Unauthorized access to the device’s file system and interception of data transmission can compromise user privacy and data integrity. 

Mitigation strategies

Encrypting stored data, ensuring secure data handling practices, and conducting thorough security testing are key ways of handling these risks. These tactics will also give a boost to your business because organizations that have experienced data breaches or have become known for practicing insecure data storage have a competitive disadvantage in today’s market. Customers will always prioritize and favor competitors with stronger data security records. This is another instance where penetration tests can be a valuable asset. 

M10: Insufficient Cryptography

The last entry on the list and another one that fell in the rankings. Insufficient cryptography in mobile applications involves exploitations by various threat agents who take advantage of the fact that many mobile application developers don’t have the proper know-how on how to implement and use cryptography and hash functions the way they are intended. Or, even worse, try to implement it from scratch.

Dangers

These agents target weak encryption, lack of HTTPS, key management flaws, and cryptographic vulnerabilities to decrypt data, manipulate cryptographic processes, or gain unauthorized access. 

Mitigation strategies

To address these risks, it’s essential to use strong encryption algorithms and implement secure cryptographic practices. Regular updates and security audits can also help mitigate vulnerabilities and strengthen the overall security layer around your business. On the OWASP web page, you can find best practices about industry-standard processes of handling keys, hash functions, validation and authentication, and more.

A security mindset changes everything

The OWASP Top 10 mobile risk ranking is just one of many open-source tools that businesses can use to improve their digital security. However, no tool or framework can be a cure-all without embracing a proper security mindset. 

When we foster a culture of security, it impacts every aspect of a business. We build this culture by recognizing that security is a continuous journey that requires ongoing vigilance, adaptation, and commitment to best practices. The OWASP list and other tools and best practices serve as a vital compass here, guiding us through the complexities of the digital world toward a future where security and business objectives are tightly linked. 

Each of these vulnerabilities presents unique challenges but also opportunities for businesses to enhance their security measures, protect sensitive data, and reinforce their commitment to being a trusted service provider for their user base.

If you need help boosting your security posture, check out our cybersecurity services.

Android app penetration testing is a must when developing an application, especially if you deal with sensitive user information. To identify the weak spots in your application’s security, it is good practice to have it tested by mobile security experts. The testing method they use for this is called penetration testing.

Penetration tests, aka pentests, are simulated cyber attacks on your application designed to find exploitable vulnerabilities. Android developers can then use the penetration test results to improve the app’s security.

The comprehensive guide to Android app penetration testing

In this blog post, we will concentrate on the networking part of Android app penetration testing – specifically on the TLS protocol, and tips on making your app as secure as possible when connecting to a specific web service.

Furthermore, this post is the first in a series of articles about pentesting, which will present an overview of what you can expect when having your app pentested. The pentesting articles will also provide recommendations on the necessary preparations ahead of it.

Disclaimer: In our examples, we will use OkHttp for the integration part, because it is a well established library and probably the most popular one in the Android community.

TLS connection

Most applications today communicate with a web service of some kind. Therefore, it’s very important to have a secure connection.

The worst case scenario is having an app that uses HTTP connection without the Transport Layer Security (TLS) protocol. It will inevitably fail because your data will be transferred in plain text – and therefore, very easy to track. TLS is a core part of encrypted communication, which makes HTTPS calls secure and authenticated.

Even though it is based on SSL 3.0, you will often hear people using SSL as a synonym for TLS- That’s not 100% correct as SSL, a predecessor for TLS, was deprecated in 2015 by the IETF.

In fact, most of the big companies are switching to TLS 1.2 as the Internet’s new minimum standard, starting from early 2020. (Mozzila, Google, Microsoft, Apple).

What does Android OS offer, with regard to TLS?

According to the documentation, Android supports TLS 1.2 since API level 16, and is enabled by default since level 21. Unfortunately, this is not 100% correct either.

Yes, you can rely on TLS 1.2 from API level 21/22 and above. However, you cannot count on that for API levels 16 to 19. There is an excellent article written by Ankush Gupta that describes this problem in more detail, so feel free to check it out if you want to know more about the how and why.

With the knowledge of what Android OS offers and the goal of achieving a secure connection using at least TLS 1.2, we’re moving on to the implementation guide.

Preparation phase in Android app penetration testing – What you’ll need to know

We will cover two specific cases in this section of the Android app penetration testing guide. The first case is when your minSdk is between API levels 16 and 19. In the other case, your minSdk is API level 21 or higher.

MinSdk between API levels 16 and 19

If you want TLS 1.2 enabled on versions before Android 5, you will have to extend the SSLSocketFactory and create your own implementation. The implementation is quite straightforward, and would look something like this:

This implementation contains our own socketFactory object, which we use as a delegate and simply update the enabled protocols.

Now that we have a custom SSLSocketFactory implementation, we have to tell OkHttp to use it via the sslSocketFactory builder parameter:

The yourTrustManagers represent an array of TrustManager instances. If you don’t know how to create your own trust manager – or if you don’t need custom implementation, you can always load the default one. You will learn how to load the default trust manager in the next section, discussing certificates.

Note that the above-stated TlsSocketFactory implementation only sets the specified protocol as the default. It does not cover the case in which the protocol is not installed on the device. To cover that instance, you will have to use the ProviderInstaller from Google Play services.

Also, keep in mind that you can either call installIfNeeded(context) or installIfNeededAsync(context), and that it has to be done before creating the TlsSocketFactory.

For a more specific implementation, you can check the sample implementation on these gists: installIfNeeded, installIfNeededAsync. These implementations are provided by the OWASP team and can be found in the OWASP-MSTG book 1.1.3 on pages 206, 207 and 208.

MinSdk API level 21+

If this is the case, you should use at least OkHttp 3.13.x – and it works only on Android 5+. If you’re already using that version of Android, you’re good to go, as this library version already uses TLS 1.2 as a default for all HTTPS calls.

If you are using an older version of the OkHttp library and cannot update it for whatever reason, you must follow the steps described in the section MinSdk between API levels 16 and 19 above.

By the way, if you are interested in the history of TLS configuration in OkHttp, this is a superb read.

Returning to the topic – now that your app uses a more secure version of the TLS protocol, it’s important to know how to successfully verify a TLS connection.

Verifying a TLS connection

Two parts are essential in the process of verifying a TLS connection:

In the following paragraphs, we’ll go over the specifics of each one.

Certificate verification (Certificate pinning)

This section of the Android app penetration testing guide will focus on certificate pinning and how to implement it. In addition, we’ll briefly examine how certificate verification is done.

For a TLS connection to work as expected, the Client must have a way of verifying that a certificate used on the server is trusted and valid. In our case, the Client is the Android app. This is where Certificate Authorities (CA) enter the stage.

A CA is an entity that is eligible to issue a trusted, time-limited certificate. The certificate issued by a CA is a verifiable small data file that contains identity credentials to help websites, people, and devices represent their authentic online identity.

But how does our Android device differentiate between the certificates issued by a CA and those so-called self-signed certificates? With the help of a set of CAs, which the device has stored on the Android system level. As of 4.2, Android contains over 100 CAs, which are updated in each release.

To view all certificates in an Android device programmatically, you can load the default TrustManager. That way, you will see all the file paths that correspond to system-level certificates and the user-installed certificates. These certificates are also known as root certificates. To retrieve the default TrustManager you can use this code:

When an Android device tries to establish a secure connection with a service, it goes through the TLS handshake process. During connection setup, the server can send an entire chain of certificates which the device has to verify with its set of trusted CAs.

The certificate chain is also known as the chain of trust, which is a linked path of verification and validation from the end user (in our case the Android device) to a root certificate.

The certificates in the chain consist of a root certificate, zero or more intermediate certificates and a leaf certificate.

Check out the image below to clarify this confusion a bit:

As you can see, the chain certificates depend on each other. This means that attackers can exploit the chain of trust even if just one of the certificates’ CA is compromised. Developers can use the compromised CA to issue a certificate that will be automatically trusted by your Android device due to the default TrustManager.

To further protect your app from fraudulently issued certificates, you can use a technique known as certificate pinning. Certificate pinning is an extra defense mechanism against MITM (ie. man-in-the-middle) attacks, in which the developer implements a custom trust manager that contains only the certificates which can validate the web server that the app is communicating with. Your app will neither trust any other system-trusted CA nor the user-installed certificates.

Certificate pinning is one of the most common test cases in a penetration test, so the following paragraph will elaborate on how to prepare an app for it.

Preparation phase in Android app penetration testing – What you’ll need to know

This section will show you how to successfully implement certificate pinning for both self-signed certificates and those issued by a CA. To pin a certificate, the first step is to decide which certificate from the certificate chain to pin.

We recommend pining the leaf certificate as the attack surface is very small, thanks to the app interacting with that certificate first. The app will not be usable if that certificate can’t be verified.

Self-signed certificates

Pinning self-signed certificates is something you should only do for testing environments. To pin a certificate in an Android app, the first thing to do is to acquire the certificate, which can quickly be done with OpenSSL via the terminal:

The command above will return a list of the entire certificate chain for the specified website. If you want to save the certificates in a local file or download one via a browser, find out how to do that here.

After acquiring the needed certificate, the next step is creating your custom TrustManager containing the certificate. This can be done as follows:

This code loads a leaf_cert_expires_1_1_2077.pem file from the raw resource folder and sets it as a certificate entry inside our empty keystore, under MyLeafCert alias. After setting the required certificate in the keystore, use the same keystore to initialize the trustManagers.

With everything ready, it’s time to pass the instance of our TrustManager to OkHttp via the sslSocketFactory builder function, as described in the TLS connection section above. We sometimes call this method hard certificate pinning because we bundle the pinned certificate in our app, and we have to upload a new version of the app that contains the new certificate every time the certificate changes or gets renewed.

Certificates signed by a trusted CA

Developers can similarly use the previous code sample for certificates signed by a trusted CA. This is a good approach if you want just one implementation for all cases. However, OkHttp does provide a different mechanism for pinning non self-signed certificates, using the CertificatePinner class. Find more information about this class here.

CertificatePinner employs a different kind of pinning, using the certificate’s subject cryptographic public key for verification. Unlike the previously described approach, in which you need to bundle the pinned certificate with your app, public key pinning only needs the base64 SHA-256 hash value of the certificate public – considering that the hash can be safely stored as a plain string in your app without causing security issues.

The implementation is much more straightforward:

So there you have it – a straightforward and intuitive approach. In addition to easier implementation, this approach has another noticeable benefit. If the certificate expires, the server can renew the certificate, without changing the cryptographic public key of the certificate.

You won’t need to update the app if the certificate gets renewed. One of the downsides of this method is that it does not support self-signed certificates.

Also, in the implementation above, you probably noticed the yourHostname.com string. This value is used for hostname verification and we will discuss this in the next section.

Finally, keep in mind that this is only a brief introduction to certificate pinning, just enough to understand the basics and to be able to prepare your app for penetration tests. For more straightforward implementation and maintenance, certificate pinning should be agreed upon with the administrators of the web service the app is communicating with, to see whether it is a good fit.

If you decide on certificate pinning, ensure a better understanding of the entire process.

Hostname verification

Finally, we’ve reached the second key part in verifying a TLS connection: hostname verification.

A common mistake developers make is setting a permissive hostname verifier, or even worse – accepting all hostnames. This means that the attacker can issue a valid certificate with a compromised CA, choose any domain name for it, and execute a MITM attack.

If you use OkHttp, the default implementation of the HostnameVerifier will be enough to verify your connection to the host. Nevertheless, we will show you a couple of examples of how to implement HostnameVerifier to gain a better understanding of how it works.

Preparation phase in Android app penetration testing – What you’ll need to know

If you aren’t using CertificatePinner for hostname verification, you can use the Java’s HostnameVerifier, as it is the base interface for hostname verification. OkHttp supports this interface, you just have to pass it to the hostnameVerifier builder function.

During the TLS handshake, the verification mechanism can call back to implementers of this interface to determine whether this connection should be allowed. The specific verification can be done using the OkHostnameVerifier, although you will stumble upon some implementations where HttpsURLConnection.getDefaultHostnameVerifier() is used.

Under the hood, this is still using the OkHostnameVerifier but from an internal Android version of the same class.

We’re ready to check a sample implementation using OkHostnameVerifier.INSTANCE.verify:

The code above will check whether the entered hostname yourHostname.com is contained inside the certificate of the current SSLSession. Only if it is, the verification will succeed. In case you want to trust an entire subdomain, you can use the wildcard pattern notation, but you will have to use the verifyHostname method like this:

Your chosen implementation will depend on your environment and all the services your app connects to.

Conclusion and notes

Hopefully, you will better understand the TLS connection and how to prepare your Android app penetration testing by this point. Look for the two critical parts of a TLS connection: certificate and hostname verification. If one of these two verifications is broken, the entire TLS connection is nullified and the app becomes an easy target for MITTM attacks.

To deepen your knowledge on handling a proper TLS connection in a WebView and more, check out the OWASP Mobile Security Testing Guide.

Also, if you (have) encounter(ed) any problems during the setup of a proper TLS connection, please check ssl-debugging for answers and solutions.

One last thing – in this post we did not cover the Android Network security configuration. This powerful tool lets apps customize their network security settings without modifying the app code.

Unfortunately, it is available only since Android 7. Still, if you are lucky enough to work on minSdk API level 24 or you are okay with having two separate pinning implementations, depending on the SDK level, then this approach should be the preferred way for handling your network configurations.

If you want to look into more ways to improve the security of your digital product, explore our cybersecurity services.