iOS's sandboxed architecture and App Store review process stop a lot of attacks, but they don't stop bad key management, leaky third-party SDKs, or a compromised build pipeline. In April 2024, researchers at E.V.A Information Security disclosed three CocoaPods vulnerabilities — CVE-2024-38366, CVE-2024-38367, and CVE-2024-38368 — that had sat unpatched for roughly a decade in the dependency manager used to build an estimated 3 million iOS and macOS apps. In September 2023, Apple shipped iOS 16.6.1 to patch BLASTPASS (CVE-2023-41064 and CVE-2023-41061), a zero-click exploit chain actively used against journalists' devices before a single line of app code ran. Neither incident required a coding mistake by the app developer. This post covers the concrete controls — data protection classes, ATS configuration, dependency vetting, privacy manifests, and runtime hardening — that reduce an iOS app's actual attack surface, not just its App Store review score.
What are the most common iOS app security vulnerabilities?
The most common vulnerabilities are insecure local data storage, weak or absent certificate pinning, and unvetted third-party SDKs, per OWASP's Mobile Application Security Verification Standard (MASVS) v2.0 categories M1, M5, and M7. In practice, this looks like API keys hardcoded in Info.plist or committed to a public repo, session tokens written to NSUserDefaults instead of Keychain, and Application Transport Security (ATS) exceptions left in production Info.plist files that permit plaintext HTTP to arbitrary domains. Static analysis of App Store binaries has repeatedly found hardcoded AWS and Firebase keys in shipped apps — a class of bug that costs nothing to introduce and everything to remediate after an app has millions of installs, because a fix requires a new build, App Store review (typically 24-48 hours, sometimes longer), and user update adoption that can take months to reach 80%+ of an install base.
How should iOS apps store sensitive data and encryption keys?
iOS apps should store credentials, tokens, and encryption keys exclusively in Keychain Services, never in NSUserDefaults, plist files, or Core Data without additional encryption. Keychain items should use the most restrictive data protection class the use case allows — kSecAttrAccessibleWhenUnlockedThisDeviceOnly for most session tokens, which ties the item to an unlocked device and blocks it from iCloud/iTunes backups, versus the weaker default kSecAttrAccessibleWhenUnlocked, which does back up. For data beyond credentials — cached PII, local databases — apps should enable Apple's Data Protection API with NSFileProtectionCompleteUntilFirstUserAuthentication at minimum, and use SQLCipher or an equivalent for encrypted local databases like SQLite/Core Data stores. A 2022 review of App Store apps by mobile security researchers found that a meaningful share of financial and healthcare apps still stored session tokens in plaintext UserDefaults, which any jailbroken device or Xcode-connected debugger can read via plutil or a simple sideloaded extraction tool.
What is App Transport Security and why does it still get misconfigured?
App Transport Security (ATS), mandatory by default since iOS 9 in September 2015, requires apps to use HTTPS with TLS 1.2+ and forbids plaintext HTTP connections unless a developer explicitly adds an NSExceptionDomains entry or sets NSAllowsArbitraryLoads to true in Info.plist. It still gets misconfigured because developers add blanket ATS exceptions during development against a local or staging server and forget to remove them before shipping — Apple's own review process does not reliably catch this, since the exception is a documented, legitimate configuration option and App Review checks for policy compliance, not runtime behavior. Beyond ATS, apps handling sensitive sessions should implement certificate or public-key pinning (via URLSession delegate methods or a library like TrustKit) to block on-path attackers who obtain a fraudulent but CA-trusted certificate — a real scenario given at least a dozen CA mis-issuance incidents logged in Certificate Transparency logs since 2015.
How do third-party SDKs and dependencies create supply chain risk in iOS apps?
Third-party SDKs and dependencies create supply chain risk because a single compromised package can be pulled into thousands of apps without any code review by the app's own security team. The CocoaPods vulnerabilities disclosed in 2024 allowed an attacker to hijack abandoned pods and push malicious code to any app that still listed them as a dependency — CVE-2024-38366 specifically allowed arbitrary code execution on the CocoaPods trunk server itself. This is not a hypothetical class of risk: in 2015, the XcodeGhost incident showed how bad it can get when attackers distributed a trojanized version of Xcode through Chinese file-sharing sites; developers who unknowingly compiled with it shipped malware into more than 4,000 App Store apps, including WeChat, which alone had roughly 500 million monthly active users at the time. Modern equivalents include malicious or typosquatted Swift Package Manager and CocoaPods packages, and analytics/ad SDKs that exfiltrate device identifiers or clipboard contents beyond their stated purpose. Every third-party dependency — SPM, CocoaPods, or a vendored binary framework — should be pinned to an exact version with a lockfile, checked against known-vulnerable version ranges, and reviewed for the runtime permissions and network destinations it actually uses, not just what its documentation claims.
What does Apple's privacy manifest requirement change for developers?
Apple's privacy manifest requirement, enforced starting May 1, 2024 for new and updated apps, requires every app and every third-party SDK using a defined set of "required reason" APIs (things like UserDefaults, file timestamp APIs, and disk space APIs) to declare a PrivacyInfo.xcprivacy file stating why. Apps that omit the manifest, or bundle an SDK that lacks one, get rejected at App Store Connect submission with a "ITMS-91053" style error rather than a soft warning — this turned what used to be a privacy-policy documentation exercise into a hard build gate. For security teams this is useful leverage: it forces an explicit inventory of every third-party SDK's data collection behavior, which is the same inventory needed to assess supply chain exposure. Apps that can't get a manifest from an SDK vendor — common with smaller or abandoned ad-tech SDKs — are functionally forced to either replace the dependency or vendor and patch it themselves.
How does jailbreak and runtime tampering detection reduce risk?
Jailbreak and tampering detection reduces risk by making the client harder to instrument for credential theft, license bypass, or automated abuse, even though no client-side check is unbeatable against a determined attacker with a jailbroken device and Frida or Cycript attached. Practical checks include testing for the existence of /Applications/Cydia.app, /private/var/lib/apt, or writable access outside the sandbox, combined with checking for suspicious dynamic libraries loaded into the process at runtime. These checks matter most for apps handling payment card data (PCI-DSS mobile guidance recommends them explicitly), DRM-protected content, or enterprise credentials, where a jailbroken device represents a materially larger attack surface for local malware to intercept Keychain access or hook API calls via tools like Frida's Interceptor. Runtime checks should never be the only control — they're a speed bump against casual attackers and automated bots, not a substitute for server-side validation, since any client-side check can eventually be patched out of a binary by a sufficiently motivated attacker with a hex editor and patience.
How Safeguard Helps
Safeguard extends the same supply chain rigor iOS teams need to third-party SDKs, CocoaPods, and Swift Package Manager dependencies that traditional mobile scanners treat as a black box. Reachability analysis determines whether a vulnerable function in a pinned dependency — like the CocoaPods trunk flaws from 2024 — is actually invoked by your app's code paths, cutting through the noise of CVE alerts that don't apply to your build. Griffin AI triages new findings against your specific Info.plist configuration, entitlements, and privacy manifest declarations to flag misconfigurations like stale ATS exceptions before they ship. Safeguard generates and ingests CycloneDX SBOMs across your iOS dependency tree so security teams have a live inventory when the next supply chain disclosure hits, and opens auto-fix PRs that bump vulnerable pod or SPM package versions directly against your repository, so remediation doesn't wait for the next sprint planning meeting.