A clear warning sign is the presence of NSAllowsArbitraryLoads set to true, which indicates the app is opting out of App Transport Security. Another sign is reliance on third-party libraries or ad providers that require HTTP or mixed transport paths. If an app still depends on insecure backend calls, it has not fully reached the intended security baseline.
What App Transport Security actually requires
app transport security, or ATS, is iOS’s baseline rule for protecting network traffic. It expects apps to use modern TLS, strong cipher suites, and valid server trust by default. When an app is properly enforcing ATS, insecure transport is treated as an exception that must be narrowly justified, not as the normal path for API calls, content delivery, or embedded SDK traffic.
A common failure pattern is that the app still “works,” but only because it has been configured to tolerate insecure connections somewhere in the stack. That can happen at the app level, in a specific domain exception, or through a third-party component that silently falls back to HTTP, weak TLS settings, or non-compliant endpoints.
How to spot an ATS exception or fallback in practice
The most obvious sign is an ATS exception in the app’s Info.plist, especially broad allowances that weaken transport policy across the app. If the configuration permits arbitrary loads, disables forward secrecy requirements, or creates domain exceptions without a clear business need, the app is not enforcing ATS in the strict sense. Those settings matter because they change the default from “secure unless exempted” to “insecure unless carefully controlled.”
Source code and runtime traces can reveal the same issue even when the plist looks clean. Look for hard-coded HTTP endpoints, mixed-content requests, older SDKs that still call plain HTTP, and ad or analytics libraries that initiate non-compliant traffic. If a security review only checks the app’s own API client and ignores bundled libraries, it can miss the exact place where ATS is being bypassed.
Another useful clue is inconsistency. If production traffic is mostly HTTPS but certain image loads, tracking beacons, login redirects, or fallback API routes still use HTTP or weak TLS, the app has not fully reached the intended transport baseline. In practice, that means the user sees a secure app shell while some sensitive data may still leave the device over weaker channels.
Why insecure transport paths are still a security problem
ATS failures are not just a configuration issue, they create real exposure at the transport layer. A single non-compliant request can be enough to leak session context, device metadata, user identifiers, or application data if the destination is intercepted or redirected. When third-party code is involved, the risk widens because the app owner may not control every endpoint, certificate decision, or protocol downgrade path.
That is why transport exceptions should be treated as part of the app’s trust boundary, not as a cosmetic warning. If an app depends on insecure backend calls, the security baseline is only partial, and the weakest dependency becomes the effective control.
Risk and Threat Considerations
ATS gaps matter because they can expose traffic to interception, downgrade, or silent leakage through SDKs that the app team does not fully govern. The main danger is not only obvious plaintext HTTP, but also the long tail of mixed transport and exception-driven access paths that bypass the app’s secure-default posture.
Failure mechanism: An attacker or intermediary can exploit an allowed insecure path, weak TLS configuration, or third-party network call to observe, modify, or redirect traffic that should have been protected by ATS.
Impact: The result can be credential exposure, data leakage, session compromise, weakened trust in the app’s transport layer, and a security review that falsely treats an app as compliant because only the primary endpoints were checked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | ATS is about enforcing secure transport for app communications. |
| Recommendation — Verify TLS-only transport, strict certificate validation, and controlled exceptions for all app network paths. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | ATS failures directly weaken confidentiality and integrity in transit. |
| Recommendation — Require protected transmission channels for sensitive app traffic and prohibit uncontrolled insecure fallbacks. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | ATS enforcement depends on strong cryptographic protection for data in transit. |
| Recommendation — Enforce approved cryptographic protections for network communications and reject weak transport settings. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Runtime testing of ATS compliance depends on observing outbound traffic and exceptions. |
| Recommendation — Monitor outbound traffic for insecure protocols, downgrades, and unexpected third-party connections. | ||
Practitioner Guidance
What to verify: Check the app’s ATS policy, then validate the effective network behavior with runtime testing. A clean plist is not enough if SDKs, redirects, or fallback endpoints still generate insecure requests.
Common mistake: Teams often review only first-party API calls and overlook ad networks, analytics SDKs, and legacy libraries. Those components are frequent sources of transport exceptions because they are treated as peripheral rather than part of the app’s real trust boundary.
What good looks like: Secure transport should be the default across the app, with exceptions documented, minimal, and individually justified. If insecure traffic still appears in routine flows, the app is not yet enforcing ATS to the standard users and reviewers should expect.
Practitioner takeaway: Treat ATS enforcement as an end-to-end runtime property, not a static plist setting, and assume the control is not effective until every meaningful outbound path is proven compliant.
Related resources from NHI Mgmt Group
- What are the signs that a mobile app is misapplying transport security or keyboard protections?
- What are the signs that iOS app security controls are not working as intended?
- How should security teams implement social login in an iOS app without failing App Review?
- How do security teams know whether an AI app's login flow is actually enforcing access control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
