Introduction

Security is a crucial criteria for anything and everything we do, be it security of family members, security of a job or even security of our credentials. Security of mobile applications is no different. Not only in case of apps facilitating critical financial transactions but in case of any and every application, security is a must. Developers must pay ample attention to the security of consumers’ data while building an application. This article will help the developer in you to understand and imbibe the various steps that he must follow to make the iOS app more secure –

1. Storage of confidential and valuable data in a secured location

Regarding storing secret stuff, Keychain is the most preferable option. User Default is also excellent when one is dealing with individual preferences, but necessary credentials, personal data, etc. should never be stored in them. Keychain might be difficult to use, but introducing a wrapper makes it much more accessible in operation. A locksmith is also a secure option if one needs to go for it.

It must be kept in mind that Keychain is made secured by the usage of a hardware module, in particular, modern devices, starting from A7 chipset, is backed up to iCloud.

Encryption of the database is also possible if one wants to, but it might prove to be difficult for Core Data, although it’s comparatively simple for Realm.

Files can also be written employing four different levels of protection. The default level is always right to go, but records can easily be made more secure as mentioned in the next step.

2. Making the networking layer invulnerable

HTTP is a firm NO. It’s certainly not recommended. By default, iOS 9.0 App Transport Security (ATS) is always enabled; therefore, one has to use HTTPS instead of non-encrypted HTTP. Though unfortunately, ATS suffers from the possibility of being easily disabled. It is of not much concern considering the fact that the application is still under development, and the server doesn’t provide any SSL yet, but in spite of this fact, an App Store build should never invite HTTP requests and ATS enabling must be ensured.

As per data of NowSecure, almost 80% of 201 of the most frequently downloaded free iOS apps opted out of ATS during December 2016. We sincerely hope that the situation is better today.

HTTPS is quite useful, but it doesn’t protect you from the attack called Man in the Middle, the very thing which SSL Pinning does. It’s a very easy technique, especially if one is using Alamofire to accomplish networking. The only underlying disadvantage is that the app must be continuously updated whenever the server’s SSL key gets changed.

3. Securing the secret keys

The secret keys shouldn’t be stored in the repository. Instead, cocoa pods-keys can be used which in a way obfuscates them. Obfuscation is not a hard job for someone like a professional app cracker, but it ensures that the raw secret values don’t become a part of Git history.

A recent thorough search for client secrets on GitHub revealed there were over 40,000 commits that possess the ability to expose an API key and a secret potentially. It’s recommended not to push one of those. It becomes imperative for public repositories to secure the secret keys, though the same thing applies to the private ones as well.

4. Being careful about third-party applications

It’s a challenging thing, but one should at least try his or her best to ensure that third-party security frameworks do not get way too vulnerable. The easiest, though not cent percent effective way, is to keep these frameworks updated to the latest stable version available. One should especially make sure that ad libraries used are genuinely safe. It’s highly recommended not to disable ATS, ever for them, even if politely asked by them.

Also Read: App Testing – A Cardinal Aspect Of Mobile App Development

5. Keyboard Caching & Securing Text Entry

This auto-complete feature in the iOS framework marks as an essential and helpful tool for typing faster and more accurate emails, messages, apps, etc. Let’s explain this. When one uses a UITextField, it in turn, enables the auto-complete feature, by which certain words get stored in plaintext to improve the auto-complete feature for the user shortly.

While dealing with a user’s password or say, other sensitive data that needs to be secured, one can always set the secureTextEntry attribute to ‘YES’ on the UITextField. Building a secured UITextField ensures that the user’s data is being hidden from the plain view and also prevents it from being unnecessarily cached on the system.

One has to have a field that doesn’t require obfuscation of the characters. By obfuscation, we mean the little dots presented in place of passwords or if one wants that the obfuscation shouldn’t be cached by the system, one can turn off auto-complete for the text field.

6. Securing The Logging

Most of us employ the use of logging to debug our applications, that is, we use the NSLog or print command, depending on the preferred programming language. These two prime commands output the necessary debug information to the Xcode developer console and thereby help in testing applications to a great extent
While it’s useful in development, if the app is released keeping these statements intact, it is implied that the data is being leaked which in turn can potentially be viewed by any malicious user.

7. Securing the Encryption Data

Of late, there has been a current pushed by different ios application developers all around the world to employ and incorporate strong encryption over the user data. Big giant companies like Google, Microsoft, and Facebook have even encrypted their data further after shocking revelations of government spying came into the limelight.

While encrypting data or encryption does add complexity to app development, it also ensures the privacy of the user’s data in case the latter’s device gets lost or stolen.

As it’s a well-known fact that small bits of data for example login credentials get automatically saved in the Keychain, but encryption offers sustainable security to large files such as documents, pictures, etc.

There’s a notion that iOS already encrypted user data. It’s not entirely wrong. In that case, the concerned user must have chosen a password for the encryption to occur. If a device doesn’t have a password setup and if by chance it ends up in unfavorable hands, all app data will be instantly accessible and that too merely with the help of a lightning cable and a computer.

8. Securing Buffer Overflows and Underflows

Buffer overflows, on the stack and heap, are a significant source of security concern in the iOS system.
Every time your program sends the input to be it from a file, from a user transmitting over some network, or by some other means, there is a strong potential or possibility to receive inappropriate and malicious data. For example, the input might be much longer than the private storage in the memory.

If the input data is extended, it will never fit into the reserved space. Unless truncated, the data will completely overwrite other data in the memory. This phenomenon is called a buffer overflow. Now if the memory that’s overwritten contains vdata valuable to the program’s operation, then this overflow causes a big bug that, being intermittent, is very hard to find. Also if the data that has been overwritten includes the address of some other code which is to be executed and the user has done this with full intent, then the user can very well insert malicious code that the target program will then run.

Similarly, when the input data is shorter than the reserved space allocated in the memory, then this condition is called a buffer underflow. This, in turn, causes many problems ranging from incorrect behavior to leaking data, currently on the stack or heap.

Also Read: Know how to Manage the iPhone App Development projects in spades

9. To be self-updated

One must keep himself updated about new vulnerabilities emerging every other day.
It’s firmly believed that the production app must not print or log in Obj-C nomenclature based statements. These are designed to debug, but any hacker/cracker can easily see them.

Conclusion
Following these steps doesn’t mean the app is hundred percent secured and invulnerable. The fight of ethics between developers and crackers is never-ending. All one can do is develop an active shield. Even if the developers try their best to build a shield, there will always be a crack. It is inevitable.