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

As the number of malicious cybersecurity attacks continues to skyrocket, mobile security is an increasingly important consideration for developers. Writing secure code for mobile apps includes implementing robust encryption protocols and user input validation.

We covered several best practices in Part 1, such as using HTTPS instead of HTTP while transferring data over any public Wi-Fi or broadband network. It’s also important to consider using POST instead of GET while sending sensitive information, as it prevents the disclosure of confidential values when they appear in URLs.

Additionally, developers should ensure that their application only accepts valid SSL certificates so they can confirm their authenticity and origin server correctly. While these are all crucial aspects of creating secure code, other key factors must be considered to ensure you're creating secure mobile apps.

Avoid data cloning

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

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

Recommended reading: Complex Digital Transformation Programs

Always encrypt data at rest and data in transit

Data at rest is stored in persistent storage, either on the client or server side. Data in transit refers to the data traveling to and from the client and server over the network. Your application data spends most of its time either at rest or in transit, making it extremely vulnerable from a security standpoint.

This is why it’s crucial to keep data encrypted, whether it’s at rest or in transit using various types of symmetric and asymmetric algorithms. As mentioned in Part 1, developers can use HTTPS best practices to encrypt data in transit. However, developers can use various database encryption techniques to encrypt data at rest. 

Sanitize sensitive data

Developers should use sanitization techniques such as encrypting sensitive data into the memory immediately after use and refrain from creating multiple or immutable copies of sensitive data. Developers can also make mutable copies and after use, set zeros on their 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 or routines. It encrypts or hides hardcoded strings in the code and secures hardcoded server URLs, usernames, passwords, and encryption keys.

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

Beware the background state

On most mobile platforms, apps stay in the background, either in a suspended, frozen,  or live state. In any case, apps still hold the memory, and, at times, their display buffers containing the screenshot of the app UI from when the app went to the background. 

If the app enters 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 or pin shown on the screen.

Developers can 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.

Recommended reading: Security Training for the Development Team

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 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 access the sensitive data 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 attackers use UI views to get sensitive data from users, it’s vital to keep autocorrection and copy/paste disabled in text fields, text input, and labels.

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 app data, classes and their interactions, and sensitive information such as username, password, API key, and tokens. This information can be useful to attackers, enabling them to reverse engineer your code and thus compromise users’ sensitive data. This is why developers should 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.

Final Takeaways

This two-part series has provided developers with the necessary tools and roadmap to writing secure code for mobile apps. By focusing on authentication and authorization, mitigating errors, and keeping data safe, you’re setting yourself up for a more successful app development experience. 

Together, these practices will protect your users from malicious threats while continuing to build trust in your app. Thanks for reading along, and check out our other resources for mobile app development below. 

Learn more:

• Read: Secure Engineering – Threat Modeling
• Watch: GlobalLogic Cafe: Guidance Framework for Selecting a Mobile Application Development Platform
• Explore GlobalLogic’s Mobile App Accelerator