Security Tenets for Mobile Applications

There is hardly a day without a security or privacy issue affecting mobile applications. A considerable amount of mobile apps, including popular ones, lack certain security and privacy requirements. When you survey current best-practices or secure frameworks, you will see a whole bunch of conditions and to-do. But there should be minimum requirements for hardening and securing any mobile applications from scratch.

I will try to present the essence of security commandments for mobile applications, especially for enterprise-level apps, without addressing a specific mobile operating system. Here is the most important security requirements or standards for securing/hardening mobile applications:

1. All communication and functions of a mobile application should be carried out over TLS/SSL or HTTPS channel.
2. The authentication mechanism of an enterprise mobile applications must rely on its directory services (Active Directory or so on) and/or SSO (Single Sign-On) feature.
3. According to the importance of the mobile application, a two-factor authentication (2FA) mechanism should be forced in the application.
4. In an enterprise, all inhouse mobile applications should be distributed and used with a mobile device management (MDM) system. And inhouse applications should never be published on public app stores.
5. The backend of a mobile application should be designed to operate in a three-tiered structure as a web/mobile server, an application server and a database.
6. There should be a strong session handling/management. Mobile apps should have a session timeout, a manual session termination (logout) and a remote logout mechanism. Also, for each user session, independently and uniquely generated tokens or security key parameters should be used.
7. Apps should support remote wipe from a stolen or lost device.
8. Runtime protection: No sensitive information should be saved or stored on the device while the application is running (runtime). The data should only be processed at runtime and then destroyed after closing the application. For the data that need to be stored in the mobile device, there should be an encryption mechanism.
9. User codes and passwords should not be used or stored as hardcoded.
10. The application should only be authorized for the device resources it will use.
11. If there is sensitive data usage or access on the application, an encryption must be used on device.
12. Apps, especially enterprise apps, should never run on the rooted or jailbroken mobile devices. So, apps should always have a jailbreaking control mechanism.
13. Tamper-detection and tamper-protection: The integrity of the apps must be ensured. There should always be an integrity check on the server-side for any changes to the installation files against tampering or intervention.
14. Android Firebase App Indexing feature should not be used for enterprise apps.
15. For enterprise apps, any analytics or performance analysis of the mobile application should not be monitored with 3rd party services. For this purpose, you may need to follow your regulations or governance practices. Also, all external 3rd party functions such as Google Tag Manager, ad manager, Facebook Connect that originate from the development environment should be disabled.
16. The mobile application should always be verified on the server-side via a device ID or token control mechanism.
17. SSL/TLS pinning should be used in apps.
18. All traffic from the mobile application’s form fields must also be encrypted.
19. “Custom” encryption and hashing algorithms designed by developers should never be used in the mobile application. You should choose at least AES-256 in symmetric encryptions, and at least SHA-256 for hashing.
20. While storing data in iOS or Android, “secure container” structure should be used.
21. To prevent the message from being intercepted or changed at any layer in service calls made in the application, cryptographic hash values of each transaction message should be generated by utilizing a predetermined private key, and these hash values should be crosschecked on the service side.
22. To prevent the replaying attack which repeats service calls in the application, a randomly generated key/nonce value should be added in the cryptographic hash calculation and by this way, each message’s uniqueness must be ensured. Also, if the unique messages are repeated, the related call/transaction should be blocked.
23. The session opened by going through the security steps in the application should be verified in each call/request/transaction.
24. The information in the messages incoming/outgoing from the app to the servers should be encrypted.
25. Authorization and permission control should be done for each transaction at the application and the service layer.
26. You should not only use or rely on the mobile operating system/device’s built-in key chains, containers or security mechanism.
27. At all stages in the service layer, error/fault management should be implemented and recorded.
28. Log records of all successful and unsuccessful service requests/responses should be created for monitoring and audit purposes.
29. You should follow static code analysis/review and security testing throughout the SDLC.

Besides above, I strongly advise you to follow the instructions published in in the OWASP Mobile Security Project.

The featured painting above is “Mustafa Kemal Pasha, speaker of the Turkish Grand National Assembly and Commander-in-Chief, Fevzi Pasha, Chief of General Staff, Kazim Karabekir Pasha, Commander of Eastern Front and Ismet Pasha, Commander of Western Front, leave for the front.” from Atatürk Museum Ankara.