Update: Apple just announced that it is postponing the ATS compliance deadline. A new deadline is unknown at this time.


During WWDC 2016, in the What’s new in Security session, Apple announced it will start enforcing App Transport Security in the App Store by the end of 2016. Our research indicates that most apps are still using keys that disable this policy and are not ready for this new regulation.

App Transport security (ATS) was introduced during WWDC 2015: “If you link your app against OS X El Capitan or iOS 9, by default it won’t be able to make any unprotected HTTP connections; they will simply fail…”

Now, with 2017 only a few days away, apps face harsher scrutiny by Apple. As if it wasn’t already tough enough getting through the review process unscathed, app publishers are now checked at the door for unsecure connections. Any irregularity and you won’t be let into the store before doing some proper explaining.

Exceptions, People, Exceptions

When Apple first announced ATS, it also introduced ways to specify exceptions for this policy on a case-by-case basis for each domain or as a global override. This global override can be added to the app’s Info.plist in the form of a new key (flag): “NSAllowsArbitraryLoads”. Setting this key to true will bypass some of the ATS requirements:

<key>NSAppTransportSecurity</key>
<dict>
 <key>NSAllowsArbitraryLoads</key>
 <true/>
</dict>

Using these exceptions means you actually turn off App Transport Security, or its key properties like using TLS 1.2. Starting January 1st 2017, using this flag will cause thorough App Store review and the app developers will have to explain why they need to use this exception in the first place.

At SafeDK we analyzed the top 4,800 apps in the iOS App Store and found that almost 75% of these apps turn off all or parts of the ATS by setting the “NSAllowsArbitraryLoads” to TRUE. As mentioned above, all these apps will face an additional App Store review for the app, and will be required to provide justifications.

According to Apple, there are a few valid reasons why an application would like to turn this security policy off:

  • An application that loads encrypted media content that contains no personalized information.
  • Connections to devices that cannot be upgraded to use secure connections.
  • Connection to a server that is managed by another entity and does not support secure connections.

While the above justifications will suffice, it should usually be backed by a specific corresponding ATS exception (as oppose to the general “NSAllowsArbitraryLoads” key). Such exception keys can reside under a “NSExceptionDomains” dictionary, for example, if you want to allow HTTP insecure connection while still upholding TLS security requirements for HTTPS connections, you can use the “NSExceptionAllowsInsecureHTTPLoads” key.

<key>NSAppTransportSecurity</key>
<dict>
 <key>NSExceptionDomains</key>
 <dict>
  <key>api.unsecured-connection.net</key>
  <dict>
   <key>NSExceptionAllowsInsecureHTTPLoads</key>
   <true/>
  </dict>
 </dict>
</dict>

You can even define the exception for all subdomains if you don’t want to commit to just one:

<key>NSAppTransportSecurity</key>
<dict>
 <key>NSExceptionDomains</key>
 <dict>
 <key>unsecured-connection.net</key>
  <dict>
   <key>NSIncludeSubdomains</key>
   <true/>
   <key>NSExceptionAllowsInsecureHTTPLoads</key>
   <true/>
  </dict>
</dict>
</dict>

This solution offered by Apple should allow the application to comply with all ATS requirements on most connections, while exempting a few specific connections (e.g. third-party SDKs connections).

Despite this fact, we see that most application developers opt for the more general and easy-to-implement “NSAllowsArbitraryLoads” key. This means that the majority of iOS apps are still using insecure connections, which in turn can endanger user and app security.

We saw 3,519 applications that had set the “NSAllowsArbitraryLoads” key to TRUE.

There are additional flags, some of which were introduced only in iOS 10, that can be used as exceptions for specific needs instead of using the global “NSAllowsArbitraryLoads” key. However, the adoption rate of these flags is very low:

11 applications are using the “NSExceptionAllowsInsecureHTTPLoads” general key. Using this key, allows for insecure HTTP connection as well as connections to untrusted HTTPS servers, but does not change Transport Layer Security (TLS) requirements.

“NSAllowsArbitraryLoadsForMedia”, for example, which allows to load media that is already encrypted and does not contain personalized information, is used by only 15 apps.

There were 11 applications that were using the “NSAllowsArbitraryLoadsInWebContent” key that allowed for web content exception, allowing the app to load arbitrary content from around the web, which cannot be guaranteed to be using HTTPS.

If you need to allow insecure connection to unqualified domains and ‘.local’ domains but don’t want to disable ATS entirely, there’s the “NSAllowsLocalNetworking” key that is currently used by 13 applications.

SafeDK research of 4800 top iOS apps shows 3 our of 4 are not compatible with ATS regulation and are in danger or being rejected by the Apple App Store review process as they

But some code in your app is not yours…

It is important to note, that while developers can (and should) make sure none of the user’s content and business logic goes out to the network on unsecured connections, they usually have little or no control over third-party servers used by integrated SDKs. SafeDK can help to identify such requests that do not comply with the ATS policy, and attribute them to specific SDKs inside the app. Gathering this information will allow apps to write fine-grained domain-specific ATS exemptions that are both acceptable by the App Store guidelines and contribute to the overall security of the application.

SafeDK In-App Protection

A More Secured Tomorrow

App Transport Security (ATS) was introduced way back in WWDC 2015, nearly 18 months ago, telling publishers that Apple is cracking down on secure connections. Since then, it has been a transition period in which you could simply exempt yourself from taking care of it, either all together or for specific cases. But that’s all about to be over.

Starting in 2017, the ATS policy would be enforced and each unsecure connection must be specified and notified in the app Info.plist file or else suffer the wrath of Apple.

We strongly urge all app developers to hurry up and get their application ready for the upcoming change in App Store policy. While the immediate benefit of following the App Transport Security is getting through the App Store review process, it is also a great step towards a more secure environment for us all.