Mobile Apps Security Guidelines

Mobile apps usually deal with users’ sensitive information like personal health info or banking info.Losing user’s personal info or getting hacked is a huge concern. there’s no bigger nightmare for any app developer than knowing due to security reasons his application users’ personal data was stolen, so it’s very important to implement the Mobile Apps Security properly.

We at Skytz Software Labs work on several apps within the health and medical sector that handles sensitive information that can’t be hacked by any third party. This is our most significant duty to secure our users’ information.

In this article, we have collected best practices to keep users’ info safe and want to share Mobile App Security guidelines with you. There are many ways to implement mobile app security for storing data, communication between applications and servers through API.and cover different aspects like auth and analytics.

If you want to check in detail, then please read our articles on iOS apps security and Android apps security.

Top Mobile Apps Security Issues and Development Strategies

Collecting sensitive data places you in a position of great responsibility. If any data is lost or leaked, it will reflect negatively on your application. As a result, your mobile app should only collect the data required for your application to function properly.

The safest data is the data you don’t collect.

it’s also important to be completely transparent about what data you’re collecting and how you plan to use it. Provide users with clear information about what data is stored where and how they can access it. Your users should be informed, but also have the ability to control what data is collected. A way to remove their personal information from your service should also be available.

General Data Protection Regulation (GDPR), which was released by the European Union, has made it legal for all software manufacturers to protect users’ data and give them full transparency and control over their collected data.

Mobile Apps Security for storing user data

Store data in your mobile app is one of the most common tasks as a mobile developer. However, many people don’t do it well and don’t follow best practices. The iOS and Android support you aggressively in this task by running your app in a sandbox and allowing default basic data encryption. But this is insufficient and needs to be improved when working with sensitive user data.

We can generally advise you to use system functionality as much as possible. One general rule of thumb is that it is always possible to use the highest level API that meets your needs. In particular, cryptography is difficult and the cost of bugs is typically so high that implementing your own cryptographic solution is rarely a good idea.

App Sandbox

All mobile apps running on either iOS or Android run in a safe location called a “sandbox.” The sandbox app is a number of fine-grained controls that restrict the application’s access to the file system, hardware, user preferences, etc. Although the iOS and Android sandbox systems are different, they share a lot of common ideas. All app data including preferences and files are stored in a single sandbox directory per application. In general, you have direct access to this folder only for your app. It can’t be accessed by any other app.

Both operating systems can overcome the sandbox’s limitations. For example, applications can ask for privileges to access the photo library of the user. However, you should be careful about these features. Hackers can hijack your app to access these files with your privileges. Don’t ask for more privileges/permissions than you need.

File encryption

The new iOS and Android OS versions have built-in and default features to encrypt files. Even if someone has access to your physical phone, they can’t read the data without decrypting it with a key, e.g. a smartphone passcode.

File encryption can be configured on both operating systems by defining file level configurations. You define how files are protected and decrypted. Encryption and decryption processes are automatically accelerated and mainly by hardware. They therefore have only a minimal impact on performance.

File Encryption in older operating systems

The operating system does not offer the same security mechanisms as for newer versions of the OS if you plan to support old OS versions (especially older versions of Android). That is why additional security mechanisms must be installed for these users.

More than 40 percent of active Android users (according to Google)  (as per Google) do not support system-wide file-based encryption and operate OS versions less than 7.0. All Android 4.4 or higher devices (96.2 percent) support full-disk encryption at least.

Therefore, to give users in lower OS versions the same level of security, you should encrypt the data on your own. We will introduce you to specific implementing techniques in our upcoming security articles on iOS and Android.

Encrypted key-value storage

We sometimes need a safe location to store small pieces of data, such as passwords or certificates. iOS and Android offer a secure data storage system called the Keychain/Keystore that encrypts all of the contents of your device. You don’t have to store encryption keys in your app and can use the system to ensure maximum Mobile Apps Security.

These safe stores are your solution for storing small pieces of data. They are the secure replacement for key-value storage for things like Android SharedPreferences or NSUserDefaults. For this type of data, these unencrypted key-value stores should be prevented.

Secure Data Transportation

Generally, keeping as much information on your device if you don’t need it on your servers is a good idea. Hacking the device allows hackers to only access the information of that particular user. That is not so much a hack-worthy goal. However, if a hacker can access the server of the app, he can access all user data. That is why you should think twice before you put sensitive data into a high-value hacker’s goal. You can never be sure your server or system has no uncovered security flaws.

Apart from preventing server hacking, it is critical to ensure the data transportation is as secure as possible:

HTTPS over SSL / TLS

This should be the default method of communication between your application and the server. HTTPS encrypts all messages sent between the client and the server, shielding them from simple man-in-the-middle attacks.

HTTPS is quite easy to add and is free of charge with services such as Let’s Encrypt. On the client-side, as a developer, you have nothing to do, as the TLS/SSL protocol is operated by the operating system.

Actually, iOS and Android expect HTTPS to be used by default. This security feature can be entirely disabled or exceptional domains can be defined if this is not possible. Anyway, in order to use the modern encryption technique, if you own the server, you should make sure you use the latest version of TLS.

HTTP Strict Transport Security

The counterpart to this HTTPS enforcement on the client is the HTTP Strict Transport Security protocol for your server. It is a web security policy to make web servers accessible only via secure connections and to protect against cookie hijacking or protocol downgrade attacks. Use it so that malicious clients cannot downgrade to an older TLS/SSL mechanism with well-known security vulnerabilities.

 

The HTTP Strict Transport Security protocol for your server is the counterpart to this HTTPS client enforcement process. It is a Web security policy that allows web servers to be accessed only with secure links and protects against cookie hijacking or protocol downgrade attacks. used to prevent malicious customers from downgrading to an older TLS/SSL mechanism with well-known security vulnerabilities.

SSL Pinning for mobile apps security

All of your messages are encrypted and make communication secure between the apps and server, but HTTPS does not guard you against complex man-in-the-middle attacks

The operating system has its own certificate trust validation by default that controls if the certificate has been signed by a trusted certificate authority with its root certificate. However, if someone has full control of the device, he can explicitly trust malicious certificates. In the worst case, a certificate authority could have been compromised.

An attacker can also run the app on his device and explicitly trust his certificates. That does not help him/her, in particular, to steal data from other users but allows the attacker to see the messages that are sent between the server and the client. This means that the malicious player can reverse the API.

Benefits of using SSL Pinning

You can pin your SSL certificates to prevent these mechanisms. You can add SSL Pinning to your mobile app by adding a list of valid certificates (or its public keys or hashes) to your App. Consequently, the app can check whether the certificate the server uses is on this list. This ensures that not only the OS but also your application relies on this certificate.

This prevents more complex man-in-the-middle attacks and also introduces some new hazards: because the app needs to hard-code trusted certificates, the app needs to be updated when a server certificate expires. If not, your app cannot connect to your server and there is no way to resolve this problem remotely (without introducing other security risks). It is advisable to insert future certificates in the customer application before release to avoid such a situation.

Prevent unauthorized access to your API by implementing security measures.

You may also want to ensure that only your mobile app can use the API of your server and block all other queries.

Many applications use some API tokens/secrets to do that. However, this is not at all safe. Hackers can easily reverse and reproduce this mechanism: for instance, attackers can pretend to be your app by manually sending the API token/ secrets (usually trying to avoid them) through their program.

You must have control over the app and its server in order to prevent these mechanisms. The customer must then authenticate himself by sending a token or signing the request. The server validates the request and only answers the real application.

Advanced checks are also available and both Apple and Google are providing secure solutions to these problems.

End-to-end encryption

All right, now we can transfer data in a secure way between our clients and our servers. The operating system and its encryption mechanisms protect our customers.

Sounds like we’re done, isn’t that? Not really! What if your servers are hacked? If we stored all sensitive data on our servers without encryption, it would be a disaster. And even if the data is encrypted, hackers may have access to the encryption key and all data can be deciphered.

The best way to prevent such attacks is to use end-to-end encryption. It ensures that only client devices that communicate can decrypt the messages. In the case of an app that can only decrypt a message from the recipient, and in the case of a health database app, only devices owned by the same person can decrypt the data. No other parties, not even the service provider, can decrypt the data.

If you can not decrypt the data yourself, it protects from assaults that are targeted at your encryption keys. You don’t have the keys and only user’s device can access these decryption keys. Even if some users are attacked or if the service provider gets hacked, the attacker doesn’t have access to any user’s data.

End-to-end encryption is not easy to implement, and we advise anyone who plans to implement Consult a second party to validate their end-to-end encryption implementation. There are many encryption algorithms available for Mobile Apps Security for example PGP, SHA-256, SHA-512 encryption.

Remote Notifications

Remote notifications are notifications sent to users’ devices by a server application. These notifications often already contain lots of information and need to be sent to one of Apple’s APNS or Google Firebase servers in order to distribute messages for you.

This means that the operating system host could theoretically intercept and read all of these messages. Apart from that, this would require our servers to store all of this data. That would contradict our goal of storing as much data locally on the devices as possible rather than on the remote server.

Both of these issues can be addressed by using silent remote notifications, which do not send actual messages to the user’s device. They will be used solely as a wake-up call for the application. The app can then retrieve the necessary information from the local device and present the user with the actual message.

Apps such as WhatsApp, telegram, protonmail, or ctemplar also use a similar technique to enable end-to-encryption and ensure the maximum Mobile Apps Security. The server sends the encrypted message to the client instead of sending a clear-text message. The client then decrypts and displays the message to the user. This prevents Google, Apple and WhatsApp from seeing the message themselves.

Best practices for code security

Analysis of Static Code and Static Application Security Testing

You may have already heard about static code analysis. It is commonly used to find a subset of bugs such as memory leaks, but there is another important use case for this: the search for common vulnerabilities in security.

Many static code analyzers (paid or commercial) are available to check your code and identify typical security issue’s. The use of these analyzers is commonly referred to as Static Application Security Testing or white box testing.

These tools checking the code before it is compiled without anything being executed. They can simply be integrated into the software development life cycle. When security weaknesses are identified in the initial stages of development, issues can be resolved quickly without complicated update cycles.

Code obfuscation

Code obscurement is a way to turn your source code into something that human beings find difficult to read. This is mainly done by automated tools before the application is built.

This does not increase the security of your code in any way. The main goal is to make the task of reversing-engineering your source code from a built program more difficult.Knowing how your source code works makes it more vulnerable to certain types of hacking attack.

Other common security risks

All of these mentioned best practices are for nothing though, if you don’t also watch out for the following things.

Third-party frameworks

3rd party SDKs or frameworks might compromise your app’s security. These SDK complied with your application and run in the same sandbox, they have the same permissions and rights as your application has. This means that a malicious SDK can get your user location or even read from your application data storage or key-chain. Don’t just trust any library you discover on the web.

Analytics

With third-party analytics SDK, less is more. Even if you build your own analytics system, be careful about what data you collect. Analytics data may frequently be used to identify people or get access to their data. For example, a crash reporting framework can access your users’ login details.

 

Conclusion

It is difficult to build secure mobile apps, but there are ways to make your applications more robust to attackers. User data protection must be a top priority and should never be ignored.

Implementing the above-recommended practices and avoiding common security risks will allow you to create more secure and safer apps.

We can propose that you generally follow this simple checklist and make sure that all these items may be ticked for your app:

• Just collect the information you really need
• If possible use higher-level APIs provided by the OS
• Use Secure storage such as AWS database  on less secure OS-versions
• Always store highly sensitive information like passwords and certificates in the Keychain / Keystore
• Don’t develop your own encryption technique.
• Use HTTPS for any sort of client-server communication
• Avoid 3rd party SDK
• Check with a second party to confirm your security idea

Even if you apply all these recommended practices to your app, this does not mean your app is not entirely secure. One simple mistake can break your whole security idea.

if you want to check deeply, check out our two follow-up articles on good iOS security and Android security practices.