IPA Security Testing, Explained

1The iOS Security Model Is Entitlement-Driven

Android's security model is largely self-declared: an app lists the permissions it wants in a manifest, and the user or system grants them. iOS works differently. Capabilities are entitlements — cryptographically signed grants embedded in the provisioning profile by Apple, not simply requested by the developer. This means an IPA's actual capability set is partly determined by what Apple's signing process authorized, not only by what's declared in the app's own configuration files. Assessing an IPA means reading the provisioning profile and entitlements directly, not just the app's stated intentions.

2What Static Analysis of an IPA Discovers

• Info.plist permissions and usage descriptions — every requested capability (camera, location, health data, and others), including whether "always-on" access like NSLocationAlwaysUsageDescription is combined with a background mode that would allow continuous tracking.
• App Transport Security configuration — whetherNSAllowsArbitraryLoads disables HTTPS enforcement globally, and whether specific domains carry an insecure-loads exception.
• Entitlements — read directly from the embedded provisioning profile, including high-risk ones like get-task-allow (debugger attachment) and Network Extension (traffic interception/filtering capability).
• Provisioning profile type — App Store, Enterprise, or Development — each with a different risk profile, covered in the next section.
• Embedded frameworks and hardcoded secrets — a full inventory of bundled .framework and .dylib files, and Mach-O binary string scanning for credentials compiled directly into the app.

An ATS misconfiguration reads directly from Info.plist, no ambiguity involved:

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
    <!-- Disables ATS globally -- every connection this app makes
         can fall back to plaintext HTTP. -->
</dict>

A tool reporting this finding would typically emit something structured like:

{
  "id": "M5-ats-arbitrary-loads-001",
  "severity": "high",
  "owasp_mobile": "M5",
  "cwe": "CWE-319",
  "evidence": "NSAllowsArbitraryLoads = true in Info.plist",
  "file": "Info.plist",
  "remediation": "Remove the global exception; add narrowly-scoped per-domain NSExceptionDomains entries only where required"
}

3Signing and Provisioning: Why iOS Is Different

A provisioning profile is Apple's cryptographic statement about what an app is allowed to do and how it can be distributed. An App Store profile means the binary passed Apple's review. A Development profile is meant for a small set of registered test devices. An Enterprise profile (ProvisionsAllDevices) can install on any device within an organization without App Store review at all — which is a legitimate internal-distribution mechanism, and also a documented distribution path for malware, since it bypasses the one consistent review step every other iOS app goes through.

The get-task-allow entitlement is a related, narrower concern: Xcode adds it automatically to debug builds so a debugger can attach, but it should never appear in a distribution build. Finding it in a shipped IPA usually means a debug configuration was accidentally released rather than a deliberate choice.

<key>get-task-allow</key>
<true/>
<!-- Present in a distribution build -- debugger attachment is
     allowed, which should only be true for a debug/dev build. -->

<key>com.apple.developer.networking.networkextension</key>
<array>
    <string>packet-tunnel-provider</string>
</array>
<!-- Grants traffic interception/filtering capability -- confirm
     this maps to an actual shipped VPN/filtering feature. -->

4Embedded Frameworks: A Supply Chain Surface

Every third-party framework bundled into an IPA runs with the same entitlements and data access as the app's own code — there's no sandboxing between an app's first-party code and an embedded analytics or advertising SDK. Static analysis can enumerate exactly what's bundled and cross-reference known frameworks against version and vulnerability data, but it can't fully audit the behavior of a closed-source framework the way it can audit the app's own compiled logic. Knowing what's embedded is the starting point for that review, not the end of it.

5What Static Analysis Cannot See

• Whether App Transport Security is actually enforced correctly at runtime — static analysis reads the configuration, not the live TLS handshake.
• Whether a declared entitlement is exercised by a reachable feature, or present but unused.
• Runtime jailbreak-detection bypass dynamics, which depend on what's actually running on the device at the moment of the check.
• Server-side logic and anything that depends on a specific sequence of runtime API calls rather than a static property of the binary.

6What Manual Review Should Still Confirm

• Whether the provisioning profile type matches the intended distribution channel — an Enterprise profile on a public-facing consumer app is worth investigating on its own.
• Whether a flagged entitlement (Network Extension, Keychain sharing) is actually used by a shipped feature, or left over from a removed one.
• Whether get-task-allow appears because a debug build was mistakenly released, and whether the release pipeline has a check to prevent that going forward.

This is standard iOS reverse-engineering territory: otool -l and class-dump against the Mach-O binary, or inspecting the embedded embedded.mobileprovision directly, are the tools most mobile security engineers use to confirm a static finding by hand — a scanner points at what to check, it doesn't replace checking it.

Two concrete false-positive/false-negative patterns worth knowing before triaging Keychain findings specifically:

• False positive — intentional keychain sharing. A shared Keychain access group is expected and safe when it's shared only across an organization's own suite of apps (a company's main app and its companion widget, for example). The finding is real (broadened access) but not a vulnerability — confirm the other app(s) sharing the group before treating it as a leak.
• False negative — entitlement present, feature removed. An entitlement can remain in a provisioning profile long after the feature that needed it was removed from the app's actual code. Static analysis correctly reports the entitlement is present; it can't tell you the capability is now unused dead weight rather than an active risk — that requires checking the code.

A concrete triage path for a flagged entitlement:

7Framework Mapping

8iOS vs. Android, Side by Side

9How This Maps to Strata

Strata reads the provisioning profile, entitlements, Info.plist, and Mach-O binary directly from every IPA scan, and flags the distinctions above explicitly rather than treating all provisioning types the same. See IPA Security Scanner for the full technical breakdown, APK Static Analysis, Explained for the Android equivalent, or the Mobile App Security Checklist for the full manual assessment methodology.