Skip to main content

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; amfid checks 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: amfid and 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, and NSAllowsLocalNetworking.
  • 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​

FeatureYou check...
Sandboxcontainer contents, sandbox profile
Entitlementscodesign -d --entitlements
Code signingcodesign -vv, resigning behavior
Keychainaccess groups, kSecAttrAccessible
Data ProtectionNSFileProtection on stored files
ATSInfo.plist NSAppTransportSecurity