Apple’s App Transport Security (ATS) ensures that network calls happen over the secure HTTP protocol (HTTPS). Unfortunately, Apple allowed for loopholes to be declared in the info.plist for apps, and many developers that couldn’t upgrade their infrastructure resorted to adopting these loopholes to make their network stack compatible. Calls over cleartext HTTP are easily snooped and spoofed, leaving app users very vulnerable to network hijinks. But, Apple never guaranteed that ATS would allow for loopholes.
At WWDC 2016, Apple finally set a date of when these gaps would be closed, and all developers will be required to use secure network protocols in their apps: January 1, 2017. Adopt the ATS model today to ensure that when Apple begins enforcing these changes, your app will not be put by the wayside.
These changes are important for users and app developers: Users will get a better experience and better privacy protection, and developers can rest easy at night knowing their customers’ data is more secure during transport from iOS and macOS devices to their servers.
While it is not yet clear how Apple will handle existing apps that are already in the store and will likely not receive updates; however, I expect we’ll see App Store rejections for new apps and app updates if the new rules are not obeyed.
Follow these steps to see how easy it can be to adopt ATS, and improve your app’s privacy for data transport.
Required ATS settings
ATS is a set of rules (not just a rule that requests need to be over HTTPS) that Apple has put into place in iOS, watchOS, tvOS, and macOS to ensure network calls are secure. Fully ATS-enabled apps will connect to servers that have the following technologies enabled:
- TLS version 1.2
- Strong cryptography using AES-128 and certificates signed with SHA-2
- Forward Secrecy (ECDHE)
These three key technologies are what Apple has determined make a network request secure for users of iOS and macOS devices. Whenever your app makes a network request, it must be made using these three technologies; otherwise, the request will be blocked by iOS or macOS. Blocked requests will be logged as an ATS incident in the console, so you can see an issue is occurring and what host the app is attempting to connect.
These ATS settings are automatically applied to all outbound network requests originating from your app. If you build your app against the iOS 10 SDK, these are the settings your app and any backend server must be configured to use.
Configuring your Xcode project
Setting up your Xcode project to use ATS is easy: Ensure your project is built with either the iOS 9 or iOS 10 base SDK, and then ensure you don’t have any exceptions listed in the info.plist–any exempted items listed in the plist will have to be explained to Apple during the app review process.
ATS rules are automatically applied to the following usage cases in iOS, macOS, tvOS and watchOS:
- NSURLSession network connections
- NSURLConnection network connection
- AVFoundation network connections
- non WKWebViews
If you utilize WKWebViews, an NSAllowArbitraryLoads exception will automatically be granted to that view so your apps can utilize the web view without experiencing issues with the network request being blocked because they are not over HTTPS.
Third-party SDKs and ATS exceptions
When ATS was announced at WWDC 2015, the exceptions feature was introduced. Exceptions will start being ignored whenever you submit your apps to the App Store with the iOS 10 and macOS 10.12 SDKs.
Most developers, especially those whose servers weren’t ready for ATS requirements, probably just used the NSAllowArbitraryLoads to generically exempt all requests from the ATS requirements. Beginning January 1, 2017, all developers must be able to justify doing this before the app enters the app review process, or else the app will be rejected due to using ATS exceptions.
Reasonable justifications required for exceptions are:
To add an exception, open the info.plist file for the target needing an ATS exception, and then create an entry that looks like Figure A.
Note that these exceptions listed in the Info.plist will have to be explained to app review whenever you submit your app for the review process. The exceptions listing will undoubtedly be similar to the way macOS sandbox exceptions are clarified (Figure B) inside of iTunes Connect.
New exceptions are being added for streaming media using AVFoundation without connecting via a TLS connection. If you’re using WKWebView, an arbitrary connection will be allowed for websites that are not HTTPS-enabled.
Forward Secrecy is a requirement of ATS, but Apple knows that most servers may not currently use this technology. Because of this, if your server does not implement forward secrecy, the exception for that will automatically be applied, but don’t expect this exception to last forever–just like the ATS requirements, forward secrecy will someday be required as well. The requirements still stand for TLS version 1.2 and strong cryptography using AES-128 and certificates signed with SHA-2 if your app will be fully ATS compatible.
Some of the reasons you may need to request ATS exceptions include:
- The server that your app data is hosted on may not be fully ATS compatible, be it TLS version or cryptography or signing methods.
- You may use a third-party service or SDK (such as Azure, AWS, or Google Cloud, Firebase, etc.) that does not yet support ATS in its Swift or Objective-C SDK.
- You may not have the time or the resources to justify adding this functionality yet.
Even though you’re requesting the exception, you should not bank on Apple allowing exceptions forever. As we move into a world where network snooping and cyberattacks are increasing, it is increasingly important for developers to take a stand and make their apps more protected against these attacks.