iOS Mobile App Security Tips

I’ve been working in the software industry for over twenty years, touching all levels of security requirements. Below are my minimum recommendations for all apps:

1. The mobile app should retrieve only the minimum amount of information required to operate from the servers.
2. All user data stored by the app, whether on disk, Keychain, or UserDefaults, should be encrypted. Do not rely on the Keychain to do the encryption for you or the iOS to enforce its protection mode.
3. Use TLS pinning to validate that the communication to/from the server is secure and not intercepted by a “trusted” certificate on the device. Make sure to also build an update mechanism so the mobile app installations can continue working when your server certificate is updated.
4. When recording logs or analytics, make sure not to record any PII (Personally Identifiable Information). You can use encryption, cryptographic hashing or tokenization, or better yet, keep the information recorded as generic as possible. Make sure those same logs and analytics do not record any API response data unless that data is once again encrypted.
5. If you store API keys or software licenses in your mobile application, do not store the information in the Info.plist or in strings. Even strings injected by your CI/CD pipeline at build time are unsafe.
   If possible, use server services, and only if required, use encryption to protect your API keys and licenses and only decrypt them in memory at runtime. Never store the decrypted keys anywhere.
6. Use only trusted third-party libraries and frameworks. If you cannot vouch for the identity or trustworthiness of the library's maintainer, you shouldn’t use it. If you insist on using it, you should do an in-depth security assessment at every update you want to include, then use cryptographic signature validation to ensure the authenticity of the library hasn’t been compromised.
7. Use a privacy screen to cover the information displayed by the app when the app is pushed to the background. This will prevent iOS from automatically capturing screenshots of your app when it goes to the background, which could lead to PII leaks.
8. When your app receives information via copy/paste, or if the user can manually enter information in a field, always validate the information entered by the user to the maximum extent possible.
   Check for maximum length, allowed characters, and the values match expectations. If the information should never leave the app, make sure to set up and use a custom Pasteboard unique to your app.
9. Use biometrics carefully. It doesn’t validate the user's identity, only that this user can use biometrics to unlock it. Often, a family will set up multiple faces or fingerprints to unlock a device, leading to multiple users passing biometric validation.
10. Validate all the data you receive from API response or even data loaded from disk previously saved by your app. A third party may have compromised or modified this data if the device is hacked.
11. Never assume that a compromised device is intentional on the user's part. Hackers may remotely take control of the device using zero-day vulnerabilities, and the user may not be aware their device was compromised.

While this list doesn’t fully represent the entire extent of security mechanisms, I find that it covers what I consider the very minimum that every app developer should do.

Even if you think the jogging route isn’t critical data, when a celebrity or diplomat enters the jogging route recorded in your app, leaking this data may risk personal harm to the individual.

If you have any doubts, play it safe. And remember to do a full threat assessment.

Community Contributions

12. Use the Swift language for new projects and allocate meaningful resources to your plan to migrate your codebase from Objective C to Swift. Use memory-safe languages for cloud server components.

13. Use automated unit tests to ensure your application architecture's designed security elements remain secure as your application evolves.

14. Use DocC to document the security features of your application design in the code so that future developers can understand the context and decisions made. This will help prevent security from being accidentally undermined by future changes to the system design.

For more information on DocC, visit https://developer.apple.com/documentation/docc

For a more complete guide to application security, you should refer to the OWASP MAS by visiting https://mas.owaps.org