To secure an iOS app, check it against the OWASP Mobile Application Security Verification Standard (MASVS), which groups controls into storage, cryptography, authentication, network, platform interaction, code, resilience and privacy. Then use Apple's platform protections, such as Data Protection, the Keychain and code signing, instead of building your own.
What is MASVS?
OWASP describes MASVS as the standard for mobile app security, usable by architects and developers building apps and by testers who want complete, consistent results. It comes with the Mobile Application Security Testing Guide (MASTG), which includes iOS-specific testing material, and the Mobile Application Security Weakness Enumeration (MASWE). The control groups are:
- STORAGE: secure storage of sensitive data on the device.
- CRYPTO: cryptography used to protect sensitive data.
- AUTH: authentication and authorization mechanisms.
- NETWORK: secure communication between the app and remote endpoints.
- PLATFORM: secure interaction with the operating system and other installed apps.
- CODE: security practice for data processing and keeping the app up to date.
- RESILIENCE: resistance to reverse engineering and tampering.
- PRIVACY: protection of user privacy in how the app collects and handles data.
What does Apple give you?
Apple's Platform Security guide documents several protections you inherit.
Data Protection. It encrypts files using a hierarchy of keys built on the device's hardware encryption. Each file is assigned to a class, and accessibility depends on whether the class keys are unlocked. Apple says third-party apps receive this protection automatically. When a file is created, a new 256-bit per-file key is generated and handed to the hardware AES engine. The Keychain also has its own data protection, which makes it the place for tokens and passwords.
Code signing and sandboxing. Apple's app security material covers app code signing, and notes that sandboxing helps protect user data from unauthorized access by apps. The platform enforces these, so your job is to avoid undermining them.
What do apps still get wrong?
The platform protects data on a locked device. It cannot protect what the app chooses to do. Constructed example: a fitness app stores an access token in a plain preferences file, logs request bodies to the console in release builds, and accepts any server certificate when a debug flag is left on. Each maps to a MASVS group: storage, privacy or storage again, and network.
Common issues to test, by group:
- Storage: secrets in preferences, plain files, backups or logs. Use the Keychain for secrets.
- Crypto: custom schemes, hard-coded keys, weak randomness. Use platform cryptography libraries.
- Auth: tokens that never expire, authentication checks done only on the device, weak biometric fallback.
- Network: disabled certificate validation, plain HTTP, unvalidated redirects.
- Platform: unsafe URL scheme or universal link handlers, data left in the pasteboard, over-broad permissions.
- Code: outdated third-party libraries, untrusted input into parsers, debug code left in.
- Resilience: none of this replaces server-side checks. Treat client-side protections as speed bumps.
- Privacy: collecting data you do not need, and sending it to third parties without disclosure.
How do you test?
Read the MASTG iOS tests for each group, run them on a build you control, and record results per MASVS control. Include the server side: the app's API is the real attack surface, because anyone can call it without your app.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers the third-party libraries your iOS project pulls in, and reachability analysis helps show whether a flagged library flaw is reachable from your code. That addresses part of the CODE group. It does not replace platform testing against MASVS.
How to check or apply this
- Choose a MASVS target level with your risk owner, and write it down.
- Walk the app's data: what is stored, where, and for how long. Move secrets to the Keychain.
- Review every network call, and confirm certificate validation is on in release builds.
- Check authentication end to end, including token lifetime and server-side authorization.
- Inventory third-party libraries and update them on a schedule.
- Remove debug code and verbose logging from release builds.
- Run MASTG iOS tests before each major release and fix findings before shipping.
Quick check
Is the iOS sandbox enough to protect my app's data?
No. It limits other apps from reading your data, but your app can still store secrets insecurely, leak them in logs or send them over weak connections.
Where should an iOS app keep a login token?
In the Keychain, which Apple documents as having its own data protection, not in plain files or preferences.
Sources
- OWASP MASVS
- OWASP MASTG
- Apple Platform Security: App security overview
- Apple Platform Security: Data Protection overview
Last reviewed: 18 October 2026.
