5 steps to make your iOS app more secure

Security is an important thing. Not only for financial apps, but for all. You should always keep it in mind. I'd like to introduce you 5 steps that are easy to do, but make your iOS app more secure.

1. Store confidential data in a secure place

Speaking in terms of storing confidential values, Keychain is the only right answer. User Defaults are fine, when you're dealing with preferences, but you should never store credentials or personal data in them. Keychain may seem to be more difficult, but using a wrapper make it much easier. I personally recommend Locksmith.

Keep in mind that Keychain is secured using a hardware module (on modern devices, A7 and newer chips) and is backed up to iCloud (that's really cool side effect).

If you want to encrypt your database it's also possible. A bit difficult for Core Data, but really simple for Realm.

You can also write your files using four different levels of protection. Default level is fine, but you can easily make your files more secure. You can read more about it here.

2. Make networking layer invulnerable

HTTP is strongly not recommended. Since iOS 9.0 App Transport Security (ATS) is enabled by default, so you have to use HTTPS instead of not encrypted HTTP. Unfortunately ATS can be easily disabled. That's fine if the app is during development and your server doesn't offer SSL yet, but an App Store build should never call HTTP requests and ATS should be enabled.

According to NowSecure 80% of 201 of the most downloaded free iOS apps did opt out of ATS in December 2016. I sincerely hope that it's much better today.

HTTPS is effective, but doesn't protect you from an attack called Man in the Middle. SSL Pinning does. It's really easy technique, especially if you're using Alamofire for networking. The only disadvantage is the app must be updated whenever the server’s SSL key is changed.

3. Think about your secret (like API) keys

They shouldn't be stored in the repository. Instead you can use cocoapods-keys that also obfuscates them. An obfuscation is probably not a big deal for a professional app cracker, but at least your raw secret values are not a part of Git history.

A search for client_secret on GitHub revealed that there are over 40,000 commits that potentially expose an API key and secret. Don't push one of these.

Now you know that it's extremely important for public repositories, but the same applies to private ones.

4. Be careful with 3rd party integration

It's difficult, but you should do your best to ensure that 3rd party frameworks aren't vulnerable. The easiest, but not 100% effective way is to keep them updated to the latest stable version. You should, in particular, make sure that ad libraries you use (if any) are safe. Don't ever disable ATS for them, even if they ask politely.

5. Keep learning

Of course that's not all. You should still learn about new vulnerabilities to be up to date. This repository can be helpful as it contains a list of the most common vulnerabilities in iOS apps.

Before the summary, I'd like to share with you two more tips.

I strongly believe that your production app should not print (or log in Obj-C nomenclature) important statements. They're designed for debugging, but hacker/cracker can easily see them.

Also you shouldn't forget about Xcode's static analysis report. You can get it by pressing ⇧⌘B. This tool helps to reveal logic flaws, memory leaks, unused variables and other bugs.

Sum up

Even following these steps doesn't mean your app is 100% invulnerable. There is an eternal war between developers and crackers. I hope this blog post could be a useful weapon.