iOS security best practices for storing sensitive data

#security#ios

Sensitive data can leak from places that seem harmless during development. Local storage, debug logs, and third-party software development kits (SDKs) all deserve a careful review.

This post covers the checks that I use as a practical starting point.

Local data storage#

iOS applications often handle passwords, secret keys, and personally identifiable information (PII). Match the storage method to the sensitivity of each value.

Do not save authentication tokens or credentials in UserDefaults without encryption.
Do not store application programming interface (API) keys or encryption keys in .plist files or hard-coded strings.

Store sensitive values in Keychain. When cryptographic keys need hardware protection, consider the Secure Enclave.

For more advanced cases, consider envelope encryption and store the root key in Keychain.

Use kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly with SecAccessControlCreateWithFlags to restrict Keychain access to an unlocked, passcode-protected device.

Logging#

Logs are useful during development, but they can expose sensitive data. Review calls to NSLog, assert, print, and any custom logging tools.

Remove log statements that include credentials, tokens, personal data, or request contents that can contain those values.

If logs are required, enable them only in DEBUG or development builds.

#if DEBUG
    NSLog(...)
#endif

Third-party SDKs#

I have integrated Firebase, Braze, and AppsFlyer into mobile applications. These services can process user behavior and advertising data.

Before you add a third-party SDK, check which data your app sends to it. I use these review steps:

Review their code, requested permissions, and known vulnerabilities.
Anonymize data before sending it to third-party services to prevent PII exposure.
Encrypt data, such as email addresses, before sending it when required.
Inspect all API requests for sensitive information. Use Proxyman to intercept and inspect traffic between the client and service.

These checks will not replace a full security review. They will help you catch common data exposure problems before a release.