There are many reasons why developers can't turn on ATS for all connections and are likely to request ATS exceptions during the app review process. For example, many apps don't talk only to their developers' servers, but also to third-party advertising, market research, analytics and image or video hosting services. The use of HTTPS on these external services are out of app developers' control.
ATS provides fine-grained exceptions like "NSAllowsArbitraryLoadsInMedia," which can, for example, be used to allow the streaming of video or audio content over HTTP, while encrypting all other connections.
However, based on Appthority's analysis, it seems that so far developers have preferred using the more generic “NSAllowsArbitraryLoads” which disables ATS for all connections, when dealing with such problems.
The company didn't find any app that used the "NSAllowsArbitraryLoadsInMedia" or the "NSAllowsArbitraryLoadsInWebContent" attributes to limit the scope of ATS exceptions. It hopes that Apple's new requirements will change that.
Many apps that do use ATS disable some of its security features. For example, none of the apps analyzed by Appthority used Certificate Transparency, which is available in ATS.
Furthermore, seven of them disabled SSL certificate validation and 46 didn't use certificate pinning. Thirty-eight apps disabled Forward Secrecy and eight apps set the allowed TLS protocol version to 1.0 or 1.1, even though the secure default in ATS is TLS 1.2.
"We still expect iOS apps with unencrypted data in enterprise environments, even after January 1," the Appthority researchers said. "When Apple approves such apps for the App Store, there will still be the security risks associated with unencrypted data for some connections, so it’s important for enterprises to have visibility into and management of the risks related to apps with those exceptions."
Sign up for Computerworld eNewsletters.