iOS Mobile App Security Tips

PublishedNovember 14, 2023

I love technology and everything related, from gadgets to new professional techniques. I like thinking, researching, optimizing, inventing and developing. I have a strong background in software research and development, operating systems, Voice-over-IP, network security, wired and wireless network engineering, complemented with electronic engineering background.

My career goal is to always keep learning, to be challenged, and to work remotely so I can be present for my family.

Bug hacker and master troubleshooter, my strength is understanding a problem and getting to the root of it. I'm mostly a self-taught individual and a constant learner. I push my technical boundaries daily and search for ways to improve my skills every day. With over 20 years of experience writing software in various languages, creating or optimizing algorithms, the digital development world is my turf.

Sample challenges which I particularly enjoyed:

Created a GLSL based magnification tool for a client who was turned down by three other companies as "impossible to do on macOS".
Optimized several SQL queries to reduce load time of a particular web page from several seconds to sub 50ms.
Identified the root cause of stuttering animations in iOS mobile app and implemented mitigation strategy

Specialties: Swift, Objective-C and PHP Software Development; TCP/IP and Wireless Network Engineering

Comments

Join the discussion

No comments yet. Be the first to comment.

More from this blog

A case for API-level cryptography

Do you rely on TLS Pinning or OS level HTTPS handling for all your API privacy? You may either break your app or insufficiently protect your information on corporate networks. It is not unusual for large corporations to use HTTPS proxy for data ins...

Feb 17, 20268 min read

Claude Code, better in pair

Improve your AI generated software development plans by running it by one of its peers.

Feb 5, 20262 min read

Strategies for dealing with Swift actor data races

When Swift introduced actors in Swift 5.5, many developers breathed a sigh of relief. Finally, a language-level construct that would protect us from data races! But here's the uncomfortable truth: actors don't eliminate data races—they just change wh...

Jan 28, 20269 min read

Strategies for dealing with Swift actor data races

Massive View Controllers and SwiftUI

Commenting on this post on LinkedIn: https://www.linkedin.com/posts/jacobmartinbartlett_the-biggest-problem-with-swiftui-is-that-activity-7261769674034409472-qGVe?utm_source=share&utm_medium=member_desktop I replied with: *The "Massive View Controll...

Nov 14, 20245 min read

Safely distributing API keys in your mobile app

The safest way is to keep your API keys server side. But if you have a library that's useable offline and it requires a license key to unlock, you will need a way to securely store that license key at runtime, without access to a server. Strap your h...

Jan 10, 20245 min read

Safely distributing API keys in your mobile app

Blog on Mobile app security and reliability on iOS and macOS.

16 posts

I'm a passionate senior iOS & macOS developer with over 13 years in the Apple ecosystem and 25 years in the software industry. I have a special interest for data security and privacy compliance!

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:

The mobile app should retrieve only the minimum amount of information required to operate from the servers.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

Here’s a reference for more information.

For a more complete guide to application security, you should refer to the OWASP MAS by clicking this link.

Command Palette

Comments

More from this blog

Community Contributions