Security in mobile applications

Implementation based on the Secure Mobile Development Life Cycle

While there are apps that run on insecure platforms, they can still be safely implemented and deliver their intended objectives. All that is required are a comprehensive understanding of the topic and the correct application of technologies, methods and processes.


Mobile apps are playing an increasingly important role in critical business areas. For financial service providers, they serve as communication channels with customers or efficient authentication solutions. For retail and e-commerce customers, they serve as convenient payment platforms for frequent transactions, etc.


Despite having strict security requirements for implementing a mobile app, the majority of today's mobile devices are considered insecure platforms. Theoretically, it is not possible to build a 100% secure solution on insecure platforms. However, practical experience shows that with the right measures, apps can be implemented in a sufficiently secure manner for their intended objectives. This article lists the most important aspects.


Key: know-how of the developers

Simply using app hardening tools  won’t do the trick. In the Secure Mobile Development Life Cycle (SMDLC), the know-how of the employees is a critical prerequisite. They must be able to assess risks and protection needs of an app before implementing the appropriate measures. A secure development environment is also required. In addition to development tools, this includes a managed repository for the source code and the artifacts (e.g. libraries) that are built into an app. A consistent identity and access management makes sure that only authorized persons have access to the development process and that it can be traced at any time who did what.


The SMDLC consists of three phases:

  • Mobile app architecture and design
  • Mobile app implementation (coding and functional isolation)
  • Keeping the mobile app secure (hardening, auditing and proactive management)
Secure Mobile Development Life Cycle

Architecture and design

The more complex the architecture, the higher the risk of vulnerabilities in a mobile app. Therefore, it has to be designed in such a way that the highest possible degree of certainty about its functioning is achieved. This also means that the basic mechanisms of the solution can be easily imparted to project staff. In addition, it is important to be able to use automated tests to verify whether the security-relevant mechanisms have been correctly implemented. 


A mobile app installed on mobile devices is out of the app provider's control. The app runs in an untrusted environment and is exposed to additional attack vectors. Where possible, critical code or critical data should be implemented on the server side in a state-of-the-art service architecture and provided via secure APIs of the app.


The functionality that runs as an app on the mobile device requires a suitable technological approach: native, hybrid or HTML5. The decision depends on the specific app requirements. Regardless of this, the basic rule is: Functionality with high security requirements is preferably implemented as native code. It is compilable in such a way that it doesn't provide metadata that simplifies reverse engineering and is therefore better protected. The expression "native code" refers to code written in C/C++. It can be integrated into both a native and a hybrid app, but not into a mobile web app.


Implementation: Secure Coding & Co.

The basic rules for secure programming are central to the actual implementation. The platform-independent OWASP Secure Coding Practices supplemented by the platform-specific Secure Coding Guidelines prove to be helpful. The latter provides guidance on correctly using the functionality of a platform. This is an important point because many of the attack vectors result from improper use of the platform functionality. A typical error is the storage of sensitive information (e.g. passwords) on the device.


Another topic is user input. It must be validated on the client and server side and cleaned from injected malware (sanitized). Special measures must be taken when entering sensitive data: As a rule, third-party keypads should not be allowed, since they sometimes send user inputs to external servers for analysis and other services. In addition, copy, caching, auto-correction and auto-completion must be switched off when entering input and web views must be avoided as they are prone to hijacking and injecting of touch events.


Functional isolation

Since the device on which the app runs is generally not trustworthy when developing mobile apps, you cannot trust a system function call from the app. An attacker could intercept the call and read or modify the parameters transferred. This is particularly critical when it comes to cryptographic functionality, where some of the parameters or return values are typically sensitive data.


This is where the concept of functional isolation comes into play. To make sure that security-critical functionality continues to work effectively on a compromised system, it is delivered as an integral part of the mobile app. It is recommended, for example, to compile the library for cryptographic operations into the app.


An additional measure is the end-to-end encryption of sensitive data on an application level. They are encrypted for transmission between the mobile app and the server by a public key compiled into the app. The private key is managed securely on the server side. This ensures that only the application has access to the data and also prevents man-in-the-middle attacks.


Hardening of the mobile app

In the next step, the mobile app is protected by so-called hardening. This includes, on the one hand, protection from integrity risks such as modifying or infiltrating code or manipulating resources (e.g. texts, URLs). On the other hand, confidentiality risks such as reverse engineering or code analysis shall be reduced by so-called code and control flow obfuscation.


These protection mechanisms come at a price: The footprint of the app (size of the app code and memory requirements) increase, while performance may decrease. Ultimately, it is crucial to find the right balance between protection and performance.


Auditing and penetration testing

The task now is to check the effectiveness of the security measures. The most sophisticated measures are useless if, for example, the mechanisms aren't correctly applied to the mobile app due to a configuration error in the build pipeline. Therefore, regular auditing of development processes and architecture decisions as well as independent testing (penetration testing, ethical hacking, etc.) of the security measures are fundamental.


Proactive app management

In order to make life even harder for potential attackers, it is advisable to use hardening periodically and upload the app to the app store even if the app hasn't changed. This way, attackers have to constantly start over in order to understand the app and find its weak points.


80 percent craftsmanship

Conclusion: When developing a mobile app, it is a good idea not to trust the environment in which it runs. Building a secure app starts with the design. The use of hardening tools is essential, but not sufficient. Developing a secure app involves 80% craftsmanship and only 20% tools. If employees have the necessary security knowledge and know their trade, they can definitely develop mobile apps that are secure enough on common platforms for their intended purpose.


This is a short version of an article published in the Swiss IT Magazine (german).