
-
-
-
-
URL copied!
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.
Trending Insights

If You Build Products, You Should Be Using...
Digital TransformationTesting and QAManufacturing and Industrial
Retail After COVID-19: How Innovation is Powering the...
Digital TransformationInsightsConsumer and Retail
Let’s Work Together
Related Content
World Usability Day: What is Usability and Why Does it Matter?
As technology becomes more and more integrated with our daily lives — from connecting with friends on Facebook to communicating with health care providers through IoTM devices — well-designed systems will be crucial to getting the information and services we all need.
Learn More
How Smart Cars Will Change Cityscapes
Which technologies do we need to improve the quality of life for people in the city and make governance more effective? What role does a car play in the city of the future, and how can it make traffic safer? GlobalLogic’s engineers are already working on solving these issues.
Learn More
Share this page:
-
-
-
-
URL copied!