Security checklist for high-performance iOS apps

Safeguard your iOS apps against common security loopholes.

By Gaurav Vaish
July 6, 2016
Diver inspecting bottom of boat Diver inspecting bottom of boat (source: tpsdave via Pixabay)

With your app running in an unknown execution environment and exchanging data over unknown transmission networks, it is important to always keep security as one of your top priorities so that you can protect users’ as well as the app’s sensitive data.

The list of malicious attacks and other areas of concern that you need to safeguard your app against is possibly endless. When testing your iOS app for security, you should run through this checklist.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

Static code analysis

  • Is NSLog used?
  • If so, NSLog is used only in debug builds
  • All URLs are HTTPS
  • Paths to local files are not hardcoded
  • Dependencies are checked for the latest versions and patches
  • No private APIs are used
  • No private keys or secrets are embedded in the code
  • No private keys or secrets are embedded in the resources
  • There is no unreachable or dead code
  • Entitlements are correct (none missing, none extra)
  • If using the connection:willSendRequestForAuthenticationChallenge: method, there is no direct branch (without any code) to useCredential:forAuthenticationChallenge:
  • App uses IDFV
  • App uses IDFA
  • Correct provisioning profile/certificate is configured for app signing
  • There are checks against SQL injection

Runtime analysis—log

  • Logging is done only to file
  • Log files are deleted periodically
  • Log rotation is implemented
  • There are no secrets or sensitive information in the log
  • No sensitive information is logged when stack trace is printed [1]

Runtime analysis—network

  • Only HTTPS URLs are used
  • Server has implementation against CRIME attack
  • Server and client app have implementation against BREACH attack
  • Client app uses certificate pinning
  • Correct caching policy is set up

Runtime analysis—authentication

  • App uses third-party authentication
  • App uses custom authentication
  • Third-party auth SDK is well audited against the remainder of this checklist
  • Login UI masks password
  • Password is not copyable
  • Access token is stored in keychain
  • App implements passcode
  • Passcode is stored in keychain
  • It is possible to change authentication workflow through a server config [2]

Runtime analysis—local storage

  • App uses local storage
  • Any sensitive information is encrypted
  • Storage is cleaned up periodically

Runtime analysis—data sharing

  • App uses shared keystore to keep common settings
  • Deep link URLs are validated
  • Any incoming data is validated
  • No sensitive data is shared to an unknown app
  • Correct group IDs are configured when using the app extensions

This checklist has been compiled from a combination of my experience working on security and also from the following sources:

1. iOS Security by Apple

2. OWASP Mobile Security Project – Security Testing Guide

3. OWASP iOS Application Security Testing Cheat Sheet

4. OWASP iOS Developer Cheat Sheet

5. Stack Overflow, “Security Analysis Tools for iOS 6”

6. Penetration Testing of iPhone Applications: Part 1 and Part 2

Following it will ensure that you have closed the commonly found security loopholes and implemented at least the well-defined measures—in the app, on the server, and in the layer between the two.


Post topics: Security
Share: