Best Practices for Writing Secure Code for Mobile Apps (Part 2)

This is the second of two posts with best practices for writing secure code for mobile apps. Read Part I here.

Avoid data cloning

Backup and restore tools helps users copy complete device data and transfer it to different/multiple devices, resulting in the cloning of you app’s data. This may result in a security threat on a user’s sensitive data.

 To avoid cloning of your app’s data, generate a unique device fingerprint and use to encrypt your app’s data. This will render the data useless on other devices, even after backup and restore.

Always encrypt data at rest and data in transit

Data at rest is the data stored in persistent storage, either on the client side or on the server side; data in transit refers to the data travelling to and from client and server over the network. Your application data spends most of its time either at rest or in transit, which makes the data extremely vulnerable from a security point of view.

So keep data encrypted whether it’s at rest or in transit using various types of symmetric and asymmetric algorithms. HTTPS best practices mentioned in the Part 1 can be applied to encrypt data in transit. Whereas various database encryption techniques can be used to encrypt data at rest.

Sanitize sensitive data

Use sanitization techniques such as encrypting sensitive data in memory immediately after use, not creating multiple copies of sensitive data and not creating immutable copies of sensitive data. Always create mutable copies and after use, reset/set zeros on its memory locations to avoid creating multiple references to sensitive data

Strip debug symbols and use obfuscation options

This increases code complexity for “bad actors” trying to reverse engineer or disassemble application code by making it more difficult to identify and understand sensitive variables, structures, and critical logic/routines. It encrypts or hides hardcoded strings in the code and secures hardcoded server URLs, user names, passwords, and encryption keys.

Another advantage of obfuscation is reduction in size. Long descriptive identifiers can be changed into small one-character identifiers with ease. Unused code can be removed and many other code shorting features are available in any good obfuscator.

Beware of the background state

On most mobile platforms, apps stay in the background, either in a suspended or frozen state, or they stays live. In either of these cases, apps still hold the memory and at times their display buffers, which contain the screenshot of the app UI from when app went to background. On the event of the app entering the background, app developers should erase or encrypt any sensitive data that the app still holds in memory and erase the display buffer for sensitive UI design views such as the password/pin shown on the screen.

Use these techniques to avoid threats from attackers accessing an app’s sensitive data when it’s in the background or from its memory or display buffer.

Disable autocorrection and copy/paste

A device’s autocorrection cache holds the data for autocomplete suggestions. These autocorrection caches are common on mobile devices and are shared across apps by the OS in order to learn user behavior and make autocomplete suggestions smarter. Although this is a useful feature from a user perspective, it may create a security threat when enabled, giving access to sensitive data entry views.

Along similar lines, copy/paste also represents a security threat to sensitive data. Attackers can use paste to get access to the sensitive data that was copied from the UI view representing sensitive data in the UI of your application. For example, allowing copying operations on a view displaying tokens, one time passwords (OTP), or passcode from the app screen may comprise them.

 Since UI views are used to get sensitive data entry from users or display data, keep autocorrection and copy/paste disabled in text fields, text input, labels, etc.

Disable logs in release builds

Debug logs reveal a lot of information about your app, such as its interaction with servers, its critical routines, storage and retrieval of apps data, classes and their interactions, sensitive information such as username, password, API key, tokens, etc. This information can be very useful to attackers in reverse engineering your app code and thus compromising users’ sensitive data. Always disable logs in the release build—no exceptions.

On most platforms, you have to disable logs explicitly, such as in iOS NSLog, which appears in both debug and release builds unless disabled using a macro.