Developing Secure Android Apps.

I’ve been developing android apps for over 3 years now and I’m also a security enthusiast. During this journey, most of the new talks and blogs in the Android community were talking about the new shiny app architecture, latest libraries, trends in Android :rocket:, etc. But I didn’t see anyone talking about security on mobile very few folks talk about it. Actually, most users don’t care about your MV.. whatever architecture or new dependency injection framework you introduced to your app as much as they care about their app data and personal info to be secure and not to be compromised :grimacing:. After all, when we finish our jobs we are also users and we want the apps we use on a daily basis to be secure :pray:. So I decided to make some researches in this area. I spent the last couple of months downloading random apps from google play with high downloads number and in the charts section to try to identify common security issues for researching purposes and make this article possible to help developers improve their security habits when developing to ensure maximum security for you and for the user.

I saw many bad practices that lead to many security vulnerabilities in these apps :scream:. I started a thread about that on twitter you can find it here but it’s in Arabic so I will summarize it in my points and give a more comprehensive view about this topic :man::computer:.

This article will be quite long so grab a cup of coffee and let’s dive into these 16 tips with detailed resources that will increase your app security . Note I’m not a security expert by any meaning I will just provide my point of view on this topic so If I had said something wrong please correct me to change it

Let’s hack it!

Gif from Giphy 1- Never ship a production app without enabling Proguard/R8

You may be wondering why I put this as the first point and there are more important things to do to secure your app. And you are right but this, in my opinion, is the most important one because it will obfuscate your code and will make it unreadable so if someone tries to reverse engineer your app with some simple tools that anyone with little experience can do to access your code and see it crystal clear as if you gave it to him on a golden plate. Code obfuscation has many benefits first of all even if your app has some security vulnerabilities it will be very hard for hackers to reach them, will also prevent some people from stealing your code, recompiling it and publishing it in the store again with some ads and make a profit from your hard work. To enable it’s pretty easy in your build.gradle file.

buildTypes { release { minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } }

This will also make your APK smaller since it will remove unused code from your APK.

Gif from Tenor

But let’s be real here it’s not just these three lines to make your app work with Proguard/R8 :crying_cat_face: you need to modify some of your code to play nice with code obfuscation and it’s really a pain in the ass to debug Proguard errors and crashes and the build will take longer time. But the benefits of it are huge this awesome blog post will show you a real-world example to avoid these kinds of problems. If you want to be even more secure and take your security to the next level you can use a paid obfustication service like DexGuard .

2- APIs must have keys and store themsafely

Most of the apps nowadays interact with some API to grab or post some data and many of them have an API key so you can’t directly call the API endpoints without this key. Unfortunately, some apps from my sample don’t have these Keys. I know it’s not an android related problem but it will affect your users and your servers severely if a hacker finds out about them. In some apps, I was able to make some requests into the API and some of them are user related endpoints. Someone can write a small script and DDOS attack your servers or steal your users’ data and both of them will ruin your business and your integrity in front of the users. So please add a key to your API and bonus point add a user token in the request header so if you see a malicious activity from one user you can immediately block it without affecting other users. I’m not an expert in this area maybe Backend developers can help us here since it’s their work . Now we have an awesome API key. How to store in the code to make it extremely hard to access it? Native code yeah :tada:. Personally, I don’t ship any application with an API key store in Java/Kotlin code because they are pretty easy to access even with Proguard enabled. So you can store it in a C/C++ file using NDK. I know when some people here the word NDK and native code they get afraid and I agree with you NDK is hard but doing this simple task of storing some strings there it’s pretty simple. You will store your API keys and other sensitive static data there and you will call it from Kotlin/Java code.

Here is a blog post to help you make that and another one here . They are quite dated so maybe I will write another article on how to do it. I didn’t do it here because this article is long enough :sleepy:.

Last thing here never ever put a server secret key in the client code :-1:

Gif from Tenor

Example of that when you are dealing with a payment API like Stripe they give you two keys a client key you can use in android(Store it in native code)and server key for payment transactions normally this key will live in your server but some folks want to take a short path to deliver the product faster so they put it in the client. Never do this because if some hacker finds it you are pretty much F*cked up.

3- You must write Firebase securityrules

We all love Firebase :heart: It’s one of the best things that happened in the tech space lately. Many apps nowadays use firebase real-time database or Firestore to store some data in it and that is perfectly fine. The problem here is that developers don’t write the database security rules for that database and that is similar to you inviting a thief to come and steal your home while you are watching something on Netflix.