Security is a key aspect of software development. Almost every mobile application deals with user information or communicates with a remote server. Even though security has improved dramatically over the past decades, it continues to be a hotly debated topic.
In this article, I would like to highlight a number of topics that are related to security and mobile development. Along the way, I touch upon a number of best practices and suggestions that you may find useful to secure the applications you write.
Security and Privacy
Security is relative. Security exploits are discovered and patched on a regular basis. Nothing is perfect. That said, there are a number of things you can do to improve the security of your mobile applications. A burglar is less tempted to break into a building surrounded by an electric fence than one that isn't.
Some developers overlook the fact that the users of their applications trust them with their information. As a developer, you are responsible for keeping that information secure. It doesn't matter what that information is. While the information may look unimportant to you, it is important to the user.
Apple takes security and privacy very serious. HealthKit is a fine example of Apple's commitment to protect the user's privacy. The user decides which health data an application has access to. While the application can request access to the user's health data, HealthKit doesn't tell it which data it has access to. In other words, Apple considers the authorization status of an application to be sensitive information it should not know about.
1. Storing Data
Should Your Application Store Data
Before you decide how or where to store a particular piece of data, you need to ask yourself whether you should store that data in the first place. Is it possible, for example, to keep the data in memory instead of writing it to disk or sending it to a remote server? This can greatly simplify your application's architecture and improve its security.
Where Should You Store Data
If you decide that storing the data locally is your only option, you need to decide where you plan to store that data. For sensitive information, such as credentials, the keychain is your best option. This is only feasible for small amounts of data your application doesn't need frequent access to.
Does the data need to be backed up to iCloud or iTunes? If that isn't the case, then you may want to consider storing the data in the Caches directory of the application's sandbox. This directory is not backed up to iCloud and iTunes. Why is that important? Data that doesn't exist cannot be compromised.
Keychain
The defaults system, accessible through the NSUserDefaults class, is a fast and convenient way to store chunks of data. Unfortunately, the defaults system is often overused by developers. It happens all too often that sensitive information, such as credentials and access tokens, are stored in the defaults system.
A much better location for storing small chunks of sensitive information is the system's keychain. As the name implies, it was designed with security in mind and it has been around for many, many years. Even though the keychain is managed by the operating system, by default, other applications don't have access to the items your application stores in the keychain.
It is true that the interface for accessing the keychain services is archaic. Fortunately, there are several excellent libraries that overcome this hurdle. Lockbox, for example, is a lightweight library for interacting with the system's keychain services. Lockbox's interface is easy to use and understand.
Keys, Tokens, Credentials
It is tempting to store keys, tokens, and even credentials in easily accessible locations, such as the target's Info.plist or a JSON file in your application's bundle. The truth is, it is child's play to extract that information from an application downloaded from the App Store. By storing an API token for a web service in your application's Info.plist, other developers can find it and use it.
2. Networking
App Transport Security
Security and privacy have been on Apple's agenda for many years and, along with other major players, Apple has decided to lead by example. During last year's WWDC, the company introduced App Transport Security.
With App Transport Security, Apple aims to improve the security of its platforms and the applications running on them. No matter how much Apple invests in securing its operating systems, a system is only as secure as its weakest component and that includes third party applications.
App Transport Security enforces applications to send network requests over a secure connection. If App Transport Security is enabled for an application, network requests are sent over HTTPS by default. Apple emphasizes its commitment to security and privacy by automatically enabling App Transport Security for applications built with Xcode 7.
You can read more about App Transport Security on Envato Tuts+. While it is easy to disable App Transport Security, bear in mind that one of the goals of App Transport Security is to make developers consider the network behavior of their applications.
Who Am I Talking To
Virtually every mobile application uses the network. This means that people with bad intensions heavily focus on this aspect of application security. Networking is a complex matter and applications build on top of a slew of technologies to fetch the data they are interested in.
As a developer, it is key that you stick to a number of best practices. We already discussed App Transport Security and the rules this new technology enforces. It doesn't stop there, though. You may also want to look into more advanced topics, such as certificate pinning to ensure the server your application is communicating with isn't fraudulent. Modern libraries, such as Alamofire, make this much easier.
3. Sensitive Information
User Data
Most applications use or store sensitive user information. Mobile devices have access to a wide range of user information that is often personal and sensitive in nature, such as location, address book, and health information.
As I mentioned earlier in this article, the first question you need to ask yourself is whether you need to access this information and, more importantly, whether you need to store that information.
If you can access the information you need through a native framework, such as HealthKit, then there is no need to duplicate and store that information. For example, Apple will reject applications that store the user's health information in iCloud.
Keep It Local
Assuming that you need to store some sensitive information, consider whether that information should be kept local. Is it necessary to send sensitive information to a remote server?
Storing sensitive information comes with a warning. If the server you are storing sensitive information on is compromised, you may be held responsible for exposing that information to other parties.
Credentials
Online security has evolved tremendously over the past decades. Authentication protocols, such as OAuth, have made communication with web services more secure and transparent.
If your application needs to talk to a secure server, consider how your application manages credentials. Does it keep them in memory or store them on disk? If you ask the user's username and password to fetch an access token, it is fine to store that access token. But should you also store username and password? The answer is no in most situations.
For applications that deal with very sensitive data, such as health or financial information, it may even be better to keep the access token in memory, not storing it on disk. Keeping it in memory makes it much safer, making your application much less of a liability. Chances are that the access token has a short lifetime anyway.
Conclusion
The security of an application is a fundamental aspect of software development. Consider what data your application has access to and whether it should store that information. If you do decide to store sensitive information, keep the above tips and best practices in mind. Make sure you treat the user's information with respect. Even though the information may look unimportant to you, it is important to the user.