Better Secure Than Sorry | Tips To Secure An iOS App

By Shantaram Kokate

Apps often deal with an abundance of private and sensitive user data like personal information, banking details, etc. Protecting these data is a responsibility — and a major one at that. Compromising data or getting hacked can have serious consequences.

In this post, we shall cover different aspects iOS application security and techniques to make an iOS app more secure.

1. Encrypted Communication

While communicating via HTTP, since communication data flow is in plain text to the network, there’s a risk of information leakage. Use HTTPS (SSL / TLS) for communication.

2. Save Important Information

If important information such as passwords and user names are saved in plain text format, there’s a high possibility such important information would be stolen when an attacker operated on the system. While saving data such as passwords or user names, save it encrypted. Save it to keychain. Since encryption is performed by the OS, there is no need to be aware of the algorithm.

3. Log Statment

Since some log output can also be viewed in release builds, it could provide an attacker with useful system information. A log should be disabled by the preprocessor macro in the release build.

You’ll need to set up a compiler flag to use the Swift preprocessor. Go to the Swift Compiler -> Custom Flags section of Build Settings to set up a -D DEBUG flag

4. Crash Report

If a crash reporting tool such as Crashlytics is not installed, it is difficult to find the crash which occurred in the production environment, and the search for a serious problem can be delayed.

It is very crucial one uses crash reporting features such as Crashlytics or Firebase.

5. Use of inappropriate Numeric type

When the Int type is used for calculation, there’s a high possibility digit overflow will occur because the maximum value is small. Also, if Double or Float is used in the calculation, there’s a risk of error.

Do not use Int, Double, Float when you need to make accurate calculations such as amount. Use a numerical calculation class NSDecimalNumber. This way, it will not overflow.

6. Privacy policy display

A product’s success is largely dependent on how much users trust it. While acquiring personal information, if the purpose of use, including whether or not the information will be provided to a third party is not specified, the element of trust is half lost there.

It’s imperative to display a privacy policy that describes the type of information that’ll be acquired and how it’ll be used.

7. Delete Temporary Data

Leaving a temporarily created file without deleting it may lead to unintended information leakage. Delete the temporarily created file at an appropriate time like when the application is closed.

8. Forced App Update Version API

If a fatal defect or security flaw is found, the app cannot be updated quickly, which may increase the damage.

The version is checked at an appropriate timing like when the application is launched. If a version upgrade is required, a notification is sent and usage restrictions are applied to the problematic version of the application.

9. Password Masking display

If confidential information such as a password is displayed on the screen, there is a risk of confidential information being stolen by peeping.

When entering or displaying confidential information such as passwords, use masking displays such as ● or *.

10. Validate User Input Value

There’s a risk of the SQL injection unless proper escaping is performed.

If you use the input value, prevent injection by using appropriate escaping, validation, placeholder, etc.

11. Certificate Information

Since the issuer information of the certificate used for signing the application might be disclosed, it could be a target of social hacking.

For the issuer of the certificate, enter the company name and dedicated representative email address, and do not enter the developer’s personal information unless there are special requirements.

12. API Response Data Cache

When communicating with URLSession etc., the communication data is automatically saved in the cache file the OS. Since this cache is stored in clear text even in HTTPS communication, it may give useful information on the system to an attacker.

When creating a URLSession, the URLSessionConfiguration urlCachecan prevent the storage of the cache by specifying nil.

Also, if URLSessionConfiguration.ephemeral is used, one can prevent the cache from being saved. But, in this case, if you destroy the URLSession, the cookies and authentication information will also be destroyed, so there is a problem using cookies for session management.

13. Avoid repeated hits and multi-tap

An indicator or progress bar is displayed while processing to make it impossible to tap the screen, and the button becomes unresponsive for about 0.2 seconds from the first button tap.

14. Don’t save sensitive information

Avoid storing important information such as user names and passwords as much as possible, and store temporary authentication information such as session tokens instead.

15. Notification Function to users

Make it possible to notify the user by sending a remote PUSH to the application. If a problem occurs, promptly notify the user, and minimise the damage.

16. Pinning

Man-in-the-middle attack can be prevented by implementing a certificate or public key match check (Pinning) in the application.

17. Information leakage due to snapshot function

If you suspend the app while the important information is displayed, a thumbnail image showing the important information is created. Since this thumbnail is displayed on the task-switching screen, important information may be stolen by peeping.

While displaying important personal information, part of it is masked and displayed.

18. Keychain

Keychain is used for saving important values ​​on both Mac and iPhone for iOS, and Apple says that it wants important values ​​to be saved in the keychain.

19. Storing keys in the Secure Enclave

The Secure Enclave is a hardware-based key manager that’s isolated from the main processor to provide an extra layer of security. Secure Enclave keeps cryptographic operations consistent even if the device kernel is compromised. Communication between the Secure Enclave and the application processor is tightly controlled by isolation in interrupted mailboxes and shared memory data buffers.

Biometric Keys, face ID, or any private key can bestore here.

20. Encrypted DataBase: SQLite

Important information in the database will be stolen when an attacker operates the system. There is a possibility to create the encrypted database by using SQLCipher pod. In SQLCipherpod, we generally follow three-steps:

• Attach
  We created an encrypted database by using a plain database.
• Export
  We copied all tables, schemes, and information in encrypted data from a plain database.
• Detached
  We deleted the plain database and started using the encrypted database.

21. JailBreak detection

This is nothing but the probability that a motivated hacker bypasses jailbreak detection.

For security reasons, we need to check if our iOS app (like banking apps, etc.) is running on a jailbroken phone or not. It’s highly recommended to check the JailBreak for the device. There are different types of JailBreak which need to be detected.

Try and hide the JailBreak check deep in your app. Don’t put it in AppDelegate because it's the first place people look for. I recommend using a library (just check out what libraries do for detection) such as IOSSecuitySuite.

22. Function And Variable Name

In function and variable name do not use words like jail, security, private_key, Cydia etc. because it helps the hacker to get know your codebase.

23. Avoid URL Scheme

iOS applications can send and receive limited data by URL Scheme (aka Deep Linking). It allows developers to launch an app through URLs (whatsapp://).

iOS URL scheme could allow a motivated hacker to hack users accounts via App-in-the-Middle attack. Attackers use a malicious app with the same Custom URL Scheme as a targeted app which can trick them into sharing users’ sensitive data with it.

Experts remarked that the URL Scheme cannot be used for the transfer of sensitive data. Make use of Universal Links instead.

24. Storing Credential Checklist

Don't store credentials locally. Instead, store credentials on your remote server. Your app user must authenticate with your server.

It’s an important responsibility to protect data of the users and I hope this post helps you get a better idea on how to go about doing so.

You can follow me on Medium for updated articles. Also, connect with me on LinkedIn, Twitter to discuss more.

Click here to read more stories on how we build our #SuperApp. 💚

Click below to build it with us.