Before to launch your Android application, you should be sure that its design is secure. For that, you have to follow these 10 basic rules. Of course, you can do more, it’s the minimum security level for any application.


Let's introduce the 10 Android app security rules.

Rule #1 — Secure the data storage

In general, your application has to save data in the device. You have to pay attention to the privacy of these data. The data can be stored in internal or external storage. If the data should only be accessible by your application, you should store them in the internal storage. Especially, all the sensitive data should be stored in the internal storage, not the external storage.

For the other data, it’s acceptable to store them in the external storage. But you should consider two points :

  • Consider encrypting these data before to store them in the external storage , for example with the Conceal library of Facebook (http://facebook.github.io/conceal).
  • Validate the data read from the external storage because this source is untrust.

Rule #2 — Secure the sharing of data cross application

When you register a Content Provider in the Manifest file, specify whether an external access to the Content Provider is permitted. For that, use the “android:exported” attribute. Set the value “true” to this attribute to authorize that, “false” otherwise set the attribute to false.

Another important point is to prevent SQL injection your query methods on the Content Provider.

Rule #3 — Secure the authentication

To secure the authentication, the first action is to not store usernames and passwords on the device. Find a solution to avoid this.

A solution, and the second action, is to use authorization tokens. This token should be refreshable, it shouldn’t be permanent.

The third action is to reduce the risk of phishing, you should reduce the requirement of user credential input in the application.

Rule #4 — Secure the Internet connection

To secure the Internet connection, you should apply two points :

  • Encrypt the Internet communication by using HTTPs wherever possible. Think about the users using the application on a public WiFi access.
  • Don’t trust data received from a not secure network access.

Rule #5 — Secure the information input

The data retrieved from the external storage should be validated as it’s not a trusted data source. This point has already been talked about here.

You should prevent the risk of SQL injection by using parameterized queries and by sanitazing raw SQL queries.

Rule #6 — Secure the communication

You should avoid communication by SMS, because it’s not a secure communication channel at all. SMS aren’t encrypted, they can be intercepted, the authentication level is low and you you can receive attacks by spoofing.

Prefer to use Firebase Cloud Messaging (FCM) services.

Rule #7 — Secure the Broadcast Receivers

If you use Broadcast Receivers, don’t forget that by default they are exported. It means that it can be invoked by other applications on the same device. If you need an exported Broadcast Receiver, pay attention to secure it in the Manifest file.

Rule #8 — Secure the services

By default, the services are not exported. It’s nice. But there is a pitfall. If an Intent filter is applied to a service in the Manifest file, this service is exported by default. So, a good practice is to use the “android:exported” attribute to ensure services are exported only when you really want they are.

Rule #9 — Secure the compiled code (bytecode)

The bytecode can be decompiled to produce source code. To prevent that, you should use a code obfuscation tool, such as ProGuard (https://www.guardsquare.com/en/proguard).

Rule #10 — Secure the dynamic loading of code

You should avoid dynamic loading of code. The risk of this operation is tampering code. But if you need to do it, you should at least ensure that this code comes from a trusted source and only transfer code over an encrypted communication.


To apply these rules doesn’t make sure that your application is secure. It’s just the minimum level of security you should apply. It’s a sanity security checklist for Android applications.


Pensées pour mieux produire

Soyez prévenu dès que mon livre "Pensées pour mieux produire" sera disponible à la vente !

DevOps, Agile, Scrum, Kanban, XP, SAFe, LeSS, Lean Startup, Lean UX, Design Thinking, Craftmanship, Management 3.0, ...

 

Bruno Delb

Agile Coach and DevOps, with an experience in the Medical Device software domain, Management 3.0, Agile games and development (especially on mobile) are my passion.

Search

Ads