DEV Community

Cover image for Pre-Launch Android App Security Checklist
Joy Winter
Joy Winter

Posted on • Edited on

Pre-Launch Android App Security Checklist

Frequent updates, complex backend, and feature-rich Android applications are released to major app stores every day. Yet, many apps become victims of cybersecurity attacks before they even get a chance to bloom.

Mobile apps can be used by employees, stakeholders, and customers, so there are various threat vectors and maintaining the security of the mobile application and the backend services is imperative for businesses today.

Some of the common mobile security exploits affecting Android apps are:

• Weak authentication and authorization
• Security vulnerabilities in servers, networks, third-party libraries, and integrated browsers
• Injection flaws, such as SQL injection
• Cross-site scripting (XSS) vulnerabilities
• Exposure of sensitive information

Implementing application security starts right from the beginning with requirements, design, and throughout the software development life cycle (SDLC).

What are the security considerations for Android mobile applications?

To help you ensure security in your Android application, here is an Android app security checklist to get you started with security considerations for designing, testing, and releasing secure Android apps.

Mobile App Security Checklist: What You Need to Do Before Launching Your Android App

This mobile application security checklist can help you get started towards maintaining application security.

Of course, you should have security experts conduct a more thorough review as this app security checklist covers mainly the basics.

#1. Protect Data Storage with Encryption and Use of the Keystore

Data storage security plays a crucial role in Android application security. You will store data on different devices, networks, or systems for all sorts of reasons, and this mobile app data could include sensitive information such as credit card info, user credentials, or much more.

You should ensure that the data you are storing is secure and encrypted to prevent data loss.

Consider using Android Keystore which provides access to a secure location for storing sensitive data, such as cryptographic keys or user credentials. When a key is generated in the secure hardware, you can also specify access controls to protect use of the key.

Additionally, make sure that no sensitive information is displayed through the mobile app user interface or exposed via IPC (inter-process communication) mechanisms. Also, no sensitive information should be written to application logs or shared with third parties unless it is an essential part of the architecture and those interactions are tightly controlled.

#2. Secure Platform Interaction by Configuring WebViews

It is important that the mobile application uses standard components and platform APIs in a secure manner. For this, ensure the mobile application only requests the minimum set of permissions necessary.

All inputs from the user and external sources must be validated and sanitized if necessary. This includes data received from the IPC mechanisms such as network sources, custom URLs, or intents.

Ensure the mobile application does not export critical features through IPC facilities or custom URL schemes unless they are properly protected. Check if WebViews are configured to allow only the minimum set of protocol handlers required. Potentially harmful handlers, such as app-id, tel, and file, should be disabled.

Make sure the WebView’s storage, loaded resources, and cache should be cleared before the WebView is destroyed. If native methods of the mobile application are exposed to WebView, it should only render JavaScript contained within the application’s package.

Moreover, the implementation of object serialization by using secure safe serialization APIs also helps maintain secure platform interaction.

#3. Leverage Cryptography to Maintain Mobile App Security

Cryptography is an important aspect of securing the user’s data, especially in a mobile environment, where attackers may have physical access to the mobile device. The purpose of using cryptography is to maintain data authenticity, integrity, and confidentiality, even while facing an attack.

Android developers should be aware of the Java Cryptography Architecture (JCA) security providers their software uses. They should consider using the highest level of the pre-existing app security framework that can support their application’s use case.

Ensure the mobile application uses proven methods of cryptographic primitives (such as one-way hash functions, digital signatures) and does not depend solely on symmetric cryptography with hardcoded keys as the only encryption process. (Don’t use hardcoded keys!!!) Make sure the mobile application does not use cryptographic algorithms or protocols that are considered deprecated for security reasons.

Use different cryptographic keys for multiple purposes to maintain mobile app security. Make sure keys are used for specific purposes and not a single key that encrypts everything. Use multiple keys to minimize the blast radius if a key is compromised.

Furthermore, make sure that all random values are created using a secure random number generator. Using KeyStore, which offers a mechanism for storage and retrieval of cryptographic keys, helps you store keys for repeated use without much hassle.

#4. Implement Strong Authentication Controls

No Android app security checklist is complete without authentication best practices. Authentication is the process of validating a user’s identity to determine whether or not they are who they claim to be. If the mobile application providers users with remote services integrate an acceptable form of authentication such as username and password at the remote endpoint.

Create a strong password policy for your mobile application that involves stringent guidelines that users must follow. Have them use long passwords or passphrases that have not been previously compromised. Also, if a user submits incorrect authentication credentials more than a specific number of times, they should be temporarily blocked from further accessing the account or asked to provide more information to prove their identity.

Authentication schemas can be complemented with passive contextual authentication including IP address, geolocation, device being used, and time of day.

Ideally, in such an authentication system, the user’s context is compared to previously recorded data to detect anomalies that might indicate potential fraud or account abuse.

Further, the mobile application should also inform the user of recent activities such as login attempts, transactions, etc.

Use multi-factor authentication which typically includes one-time passwords via time-based tokens or email on registered contact details, secure tokens, PINs, biometric authentication, and more to validate a user’s identity.

#5. Using TLS Certificates to Protect Data-in-Transit

Network security in Android apps is inherently risky, as it involves transmitting data that is potentially personal to the user (and back to the servers).

Mobile users are increasingly becoming familiar with privacy and security concerns of mobile apps, especially if an Android app performs transactions across the network, so it’s essential that your mobile application implements all mobile app security best practices towards keeping the user’s data secure at all times.

Data-in-transit should be secured, which means the sending/receiving and stored data inside your application should be secured with TLS or VPN tunnel communication.

Having these certificates and processes integrated into your application’s network helps build a secure channel consistently throughout the mobile application.

For instance, a transport layer security (TLS) helps encrypt data as it moves on the network. The TLS settings should ideally follow best practices, or as close to the recommended standards as possible if the mobile operating system does not support the standard practices.

Attacks that can be induced from input data over an IPC or network when using native code should be controlled properly by managing buffers and handling the pointers. When a secure channel is established, the mobile application should verify the X.509 certificate of the remote endpoint. Only certificates signed by a trusted CA are accepted. Preferably, pin your certificates.

Understanding Mobile App Defense In-Depth

No sensitive app data should be included in the backups generated by the mobile’s operating system. Also, the Android app should not hold any sensitive data in memory longer than required, and memory should be clearly explicitly after use.

The Android app should enforce a minimum device-access-security policy, which requires the user to set a device password. Access tokens and sessions should be invalidated at the remote endpoint once a user has logged out of the application or after a predefined period of time.

In addition to this, the mobile app should not rely only on a single insecure communication channel (SMS or email) for sensitive operations, such as account recovery, sensitive transactions, or enrollments.

The application should also be able to detect if it’s running on a rooted device and depending on the business requirements, either the app should be terminated or the users should be warned if the device is rooted.

The mobile application should notify users about all login activities via email or SMS providing them a list of devices used to access their account, the time and location from where the app was accessed, and give an option to block specific devices.

Is Your App Ready to Launch?

Maintaining mobile app security is highly recommended as the number of cyberattacks targeting mobile apps is continuously on the rise. This Android application security checklist will help you ensure that your application follows the best security practices and protect your users from becoming a victim of a cyberattack.

Other than focusing on the app’s security aspects, it’s also prudent to give a thought to safeguarding all those expensive branding ventures like that expensive business logo design.

Top comments (3)

Collapse
 
exadra37 profile image
Paulo Renato

Congrats for you excellent article and advice :)

Preferably, pin your certificates.

I would say always pin, but it's a very complicated area with a lot of potential for shoot yourself on the foot, thus a developer must really understand what is doing and understand all the implications for the mobile app when rotating certificates in the backend. I have wrote the article Securing Https with Certificate Pinning on Android that can help developers to implement it on Android. I realize now that I could write another article just around the shout on the foot scenarios.

Collapse
 
shostarsson profile image
Rémi Lavedrine

That is an interesting article.

Indeed Certificate pinning is a pretty good defense in depth.
Because, using mobile apps let an attacker know all the requests and response (your all API basically) as it can decrypt easily https.
And so, it is easy to know the request body, even if you hided it in a POST (as the body is encrypted with https).

Moreover, I would say, that for very specific app (banking app, etc...), you should obfuscate your application.
I wrote this article about application obfuscation :


Dexprotector is a pretty good obfuscator.

And to try your tools against an on-purpose vulnerable app, you can use InsecureBank-v2

GitHub logo dineshshetty / Android-InsecureBankv2

Vulnerable Android application for developers and security enthusiasts to learn about Android insecurities

InsecureBankv2 Readme

Black Hat Arsenal

Black Hat Arsenal

This is a major update to one of my previous projects - "InsecureBank". This vulnerable Android application is named "InsecureBankv2" and is made for security enthusiasts and developers to learn the Android insecurities by testing this vulnerable application. Its back-end server component is written in python. It is compatible with Python2. The client component i.e. the Android InsecureBank.apk can be downloaded along with the source. The list of vulnerabilities that are currently included in this release are:

  • Flawed Broadcast Receivers
  • Intent Sniffing and Injection
  • Weak Authorization mechanism
  • Local Encryption issues
  • Vulnerable Activity Components
  • Root Detection and Bypass
  • Emulator Detection and Bypass
  • Insecure Content Provider access
  • Insecure Webview implementation
  • Weak Cryptography implementation
  • Application Patching
  • Sensitive Information in Memory
  • Insecure Logging mechanism
  • Android Pasteboard vulnerability
  • Application Debuggable
  • Android keyboard cache issues
  • Android Backup vulnerability
  • Runtime Manipulation
  • Insecure SDCard storage
  • Insecure HTTP connections
  • Parameter Manipulation
  • Hardcoded secrets
  • Username Enumeration issue
  • Developer…

I created some tools to automate penetration testing on android mobile applications and tried it against this app as a first try during development before trying it against other applications.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt

What about full-stack web app, with user logins?