iOS Security Features
These are the platform mechanisms that define what you can and cannot do as a tester. Knowing them tells you what the app should be protected by, and therefore where the weaknesses actually are.
App Sandbox
Every app runs inside its own sandbox container under /var/mobile/Containers/Data/Application/<UUID>/.
- Each app gets a unique container; it cannot read or write outside it without explicit permission.
- Enforcement happens in the kernel via a compiled sandbox profile and the
sandbox_check()API. - A sandbox escape is the prerequisite for most local attacks; jailbreaks provide sandbox-escape primitives.
Why it matters: sandboxing is the app's real boundary. On a non-jailbroken device you cannot casually read another app's files, which forces you to work through the app's own interfaces (or a jailbreak).
Entitlements
Entitlements are signed key/value pairs in the app's code signature that grant specific capabilities:
- e.g.
keychain-access-groups,aps-environment(push),com.apple.developer.team-identifier. - Apple validates entitlements at install/launch;
amfidchecks them against the signature.
Why it matters: check an app's entitlements early (codesign -d --entitlements). Overly broad entitlements (like com.apple.private.* on a jailbroken build) are immediate red flags, and entitlement misuse is a common root cause of broken authorization.
Code Signing
Every binary and bundle on iOS is signed by a certificate chain back to Apple.
- App Store builds are signed by Apple; development builds are signed with the developer's certificate.
- Enforcement is continuous:
amfidand the kernel check signatures as code executes. - The simulator does not enforce this strictly, which is one reason it is friendlier to testing.
Why it matters: code signing is what you bypass when you resign an app (e.g. with a "signing" tool) or patch a binary on a jailbroken device. Unsigned or ad-hoc signed apps run only on jailbroken/jailbroken-friendly setups.
Keychain
The encrypted store for secrets (passwords, tokens, certificates).
- Backed by the Secure Enclave on modern devices; items are encrypted with keys derived from the device UID.
- Access controlled by
kSecAttrAccessible(Data Protection classes) and access groups (shared across apps with matching entitlements).
Why it matters: the Keychain is where apps should store credentials. Test whether they do, and test Keychain access-group sharing, a second app in the same group can silently read the first app's items.
Data Protection (File Protection Classes)
File-level encryption tied to device lock state, controlled by a NSFileProtection* attribute:
NSFileProtectionNone: accessible anytime.NSFileProtectionComplete: accessible only while device is unlocked.NSFileProtectionCompleteUntilFirstUserAuthentication: after first unlock.NSFileProtectionCompleteUnlessOpen: open handles keep access after lock.
Why it matters: files with None survive in backups and in forensics of an unattended device. Auditing which files lack protection (especially databases and key stores) is a core finding.
Secure Enclave
The SEP (covered in the architecture note). Holds hardware keys, performs biometric matching, and protects Keychain/Data Protection key hierarchy.
Why it matters: you will not break the SEP in a normal engagement. Design your testing around the fact that device-held secrets (if the app uses them properly) are effectively out of scope, focus instead on the app's own weak storage and handling.
Face ID / Touch ID
Biometric authentication, matched inside the Secure Enclave.
Why it matters: apps often treat a successful biometric check as proof of identity, but a weak fallback (passcode, or skipping re-auth after a timeout) undermines it. Also test whether a different biometric-enrolled user or a duplicated/simulated device changes app behavior.
App Transport Security (ATS)
A default-on policy that requires HTTPS for all NSURLSession/CFNetwork connections.
- Exceptions exist:
NSAllowsArbitraryLoads, per-domain exceptions, andNSAllowsLocalNetworking. - Related: certificate pinning (optional, implemented in app code, not by ATS).
Why it matters: ATS violations mean the app talks cleartext HTTP or accepts broken TLS, prime targets for traffic interception. Check Info.plist for NSAppTransportSecurity exceptions and test for the absence of certificate pinning by running the app through a proxy.
Cheatsheet
| Feature | You check... |
|---|---|
| Sandbox | container contents, sandbox profile |
| Entitlements | codesign -d --entitlements |
| Code signing | codesign -vv, resigning behavior |
| Keychain | access groups, kSecAttrAccessible |
| Data Protection | NSFileProtection on stored files |
| ATS | Info.plist NSAppTransportSecurity |