Security Best Practices in iOS

Take a look at techniques that you can use right now to make your iOS apps more secure.

TL;DR: Nowadays, we use our smartphones to do almost everything, from sending a simple email to making a wire transfer. Those tasks are performed over the internet, which means that you're exposed to possible security attacks.

You need to understand that security risks are always going to exist, and you can never make your software 100% secure. What you can do is mitigate those risks and reduce them as much as possible.

As a mobile developer, you should try to make your application as secure as possible. Imagine that you're building an application for a bank institution. What happens to your client's reputation if a security breach occurs? And what about your client's customers? Imagine someone using a preventable security leak to steal their money.

Let's go over some techniques that you could start applying right now to make your mobile applications a little more secure.

What Should You Pay Attention To?

As a developer, there are four major subjects that you must check when you're developing an iOS application:

1. Data storage
2. Data communications channels
3. Jailbroken devices
4. Development techniques

I’ll cover each of these below.

Data storage

Depending on the information you're storing, you'll need to use different mechanisms to increase your application's security level.

App files

If you need to save files in your app's directory, you should use the built-in Data Protection API feature. This feature allows you to specify a level of protection for a file. If the user sets and uses a device passcode, Data Protection will be automatically enabled.

There are four levels of Data Protection available:

• No protection. The file is always accessible.
• Complete until first user authentication. This is the default value. The file will remain encrypted until the user unlocks the device for the first time. After that, the file will be accessible until the device shuts down or reboots.
• Complete unless open. The file will remain encrypted until the application opens the file, and the application can open files only while the device is unlocked. Open files are accessible even when the device is locked. New files can be created and accessed whether the device is locked or unlocked.
• Complete. The file will remain encrypted until the user unlocks the device and becomes encrypted when the user locks it.

You've got two options to set the encryption level for a file:

Option 1: Using the [write(to:options:)]](https://developer.apple.com/documentation/foundation/data/1779858-write) method. With this, you can create a file and assign it a protection level all at once:

do {
  try data.write(to: fileURL, options: .completeFileProtection)
} catch {
  // Handle errors.
}

You can check out the encryption options here.

Option 2: Setting the data protection level for an existing file using the setResourceValue(_:forKey:) method:

do {
  try (fileURL as NSURL)
    .setResourceValue(
      URLFileProtection.complete,
      forKey: .fileProtectionKey
    )
  } catch {
    // Handle errors.
}

UserDefaults

Sometimes you need to store some user preferences. For example, the user might want the sign-in screen to remember them. You’ll want to persist this kind of information between application launches.

Through the use of the UserDefaults class, Apple gives us an easy way to save and retrieve information as key-value pairs.

// Save the boolean value `true` under the key `rememberUser`
UserDefaults.standard.set(true, forKey: "rememberUser")

// Retrieve the boolean value stored under the key `rememberUser`
let rememberUser = UserDefaults.standard.bool(forKey: "rememberUser")

The problem is that it’s too easy to use UserDefaults. This ease of use can mean that you might end up using it to store sensitive information — such as API tokens, for instance.

You should never use UserDefaults to store data that could compromise your application. When using UserDefaults to store some piece of data, ask yourself: "What could happen if someone accessed the information in UserDefaults?" If any of the answers mean that your application could be breached, you shouldn't store that data in UserDefaults.

Read more...