Security cheat sheet

The 7 Security interview answers in 30 seconds each, plus quick facts. Printable, free.

One page per topic: print it or save it as PDF from your browser's print menu. Practise these questions

The pillars of iOS app security

Protect data at rest (Keychain for secrets, file protection, no sensitive data in logs or UserDefaults), data in transit (HTTPS with ATS, optionally pinning), and access (strong authentication, biometrics backed by the Keychain, short-lived tokens). Rely on the platform (sandbox, code signing, App Attest) and assume the client can be inspected, so the server enforces every rule that matters.

Certificate and public key pinning

Pinning makes the app trust only specific keys for your servers, which blocks interception through other trusted or user-installed certificates. Pin the public key (SPKI hash) rather than the whole certificate, include at least one backup pin, and declare it with NSPinnedDomains in Info.plist or check it in a URLSession authentication challenge. Plan key rotation, because a wrong pin locks every user out until they update.

Face ID and Touch ID done securely

For a simple gate, LocalAuthentication's LAContext.evaluatePolicy returns success or failure, but that boolean can be tampered with on a compromised device. To protect a secret, store it in the Keychain with an access control such as .biometryCurrentSet, so the Secure Enclave releases it only after a successful biometric check. Add NSFaceIDUsageDescription and offer a passcode fallback.

Jailbreak detection

Jailbreak detection looks for signs of a modified device, such as known files, writable system paths or injected libraries. Every check runs on a device the attacker controls, so it can be bypassed. Treat it as one risk signal, and rely on server-side checks such as App Attest and DeviceCheck, plus limits that hold even on a compromised device.

Protecting API keys

Assume anything shipped in the app can be extracted, whether it is in code, plists or obfuscated. Keep real secrets on your server and have the app call your backend, which adds the key. For keys that must ship, such as public SDK keys, restrict them with the provider (bundle ID, quotas, scopes) and protect your own endpoints with authentication and App Attest.

App sandboxing

Each iOS app runs in its own sandbox: it can read and write only its own container and must ask permission for protected resources like photos, location and contacts. To share data with your own extensions or apps, use an App Group container and shared Keychain access groups. To share with other apps, use the share sheet, document pickers, or universal links and URL schemes.

End-to-end encryption in a chat app

The server can't read messages, so everything that needs plaintext moves to devices: search, previews, link previews and moderation signals. Keys are generated and kept on each device in the Keychain or Secure Enclave, with a protocol for key exchange, multi-device and recovery. Push notifications carry encrypted payloads that a Notification Service Extension decrypts before display.

Quick facts

Secure Enclave: A separate processor that holds keys and biometric data; keys created there can't be extracted.
File protection: Classes such as .complete make files unreadable while the device is locked.
App Attest: DCAppAttestService creates a hardware-backed key and attestations your server verifies.