The importance of and attention for security on the web has increased substantially over the past few years. During this year's WWDC, Apple has made it clear that it plans to lead by example by improving security of its operating systems through a new feature, App Transport Security.

Of course, the security of a platform is only as strong as the security of its components and that includes third party applications. In other words, Apple expects developers to adopt App Transport Security in their applications.

In this article, I will explain what App Transport Security entails, how it will affect your applications, and how you can update your applications to stick to Apple's guidelines and recommendations.

What Is App Transport Security?

App Transport Security, or ATS for short, is a new feature of iOS 9 and OS X El Capitan. While Apple didn't mention watchOS, we can assume App Transport Security also applies to watchOS 2. App Transport Security aims to improve the security of Apple's operating systems and any applications running on these operating systems.

Network requests that are made over HTTP transmit data as cleartext. It goes without saying that this poses a significant security risk. Apple stresses that every developer should strive to keep the data of their customers safe and secure, even if that data doesn't seem important or sensitive.

App Transport Security actively encourages security by imposing a number of security best practices, the most important being the requirement that network requests need to be sent over a secure connection. With App Transport Security enabled, network requests are automatically made over HTTPS instead of HTTP.

There are a number of other requirements to further improve security. For example, App Transport Security requires TLS (Transport Layer Security) 1.2 or higher. While you may be unfamiliar with TLS, I'm sure you've heard of SSL (Secure Sockets Layer). TLS is the successor of SSL and is a collection of cryptographic protocols to enforce security over network connections.

Apple recently published a public, prerelease technote about App Transport Security to give developers the opportunity to plan for App Transport Security. The document outlines what App Transport Security expects from your applications and the web services it interacts with.

Exceptions

Wait a second. My application uses a CDN (Content Delivery Network) that I don't have control over and it doesn't support HTTPS. Don't worry. Apple has your back covered. With regards to App Transport Security, an application falls into one of four categories. Let's go over each category to see how it impacts an application.

HTTPS Only

If your application only interfaces with servers that support HTTPS, then you're in luck. You're application won't have to make any changes. However, note that App Transport Security requires TLS 1.2 and it expects the domain to use ciphers that support forward secrecy. The certificate also needs to meet the requirements imposed by ATS. It's therefore important to double-check that the servers your application communicates with comply with the requirements of ATS.

Mix & Match

It is possible that your application talks to servers that don't meet the ATS requirements. In that case, you need to tell the operating system which domains are involved and specify in your application's Info.plist what requirements aren't met.

This means that App Transport Security is enforced for every endpoint your application talks to with the exception of the ones specified in your application's Info.plist. You can configure the exceptions using a number of predefined keys. In the following Info.plist, we define three exceptions.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    ...
	<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSExceptionDomains</key>
		<dict>
			<key>api.insecuredomain.com</key>
			<dict>
				<key>NSExceptionAllowsInsecureHTTPLoads</key>
				<false/>
			</dict>
			<key>cdn.somedomain.com</key>
			<dict>
				<key>NSThirdPartyExceptionMinimumTLSVersion</key>
				<string>1.1<string/>
			</dict>
			<key>thatotherdomain.com</key>
			<dict>
				<key>NSIncludesSubdomains</key>
				<true/>
				<key>NSExceptionRequiresForwardSecrecy</key>
				<false/>
			</dict>
		</dict>
	</dict>
	...
</dict>
</plist>

api.insecuredomain.com

The first exception we define tells ATS that communication with this subdomain overrides the requirement to use HTTPS. Note that this exception only applies to the subdomain specified in the exception. It's important to understand that the NSExceptionAllowsInsecureHTTPLoads key doesn't only relate to the use of HTTPS. The exception specifies that, for that domain, every requirement of App Transport Security is overridden.

cdn.domain.com

It's possible that your application talks to a server that serves its data over HTTPS, but isn't using TLS 1.2 or higher. In that case, you define an exception that specifies the minimum TLS version that should be used. This is a better and safer option than completely overriding App Transport Security for that particular domain.

thatotherdomain.com

The NSIncludesSubdomains key tells App Transport Security that the exception applies to every subdomain of the specified domain. The exception further defines that the domain can use ciphers that don't support forward secrecy (NSExceptionRequiresForwardSecrecy) by expanding the list of accepted ciphers. For more information about forward secrecy, I recommend reading Apple's technote on the topic.

Opt Out

If you're building a web browser, then you have a slightly bigger problem. Because you don't know which web pages your users are going to visit, you cannot possibly tell whether those web pages are served over HTTPS and meet the ATS requirements. In that case, there is no other option but to opt out of App Transport Security altogether.

It's important that you explicitly opt out of App Transport Security. Remember that App Transport Security is enforced by default. In your application's Info.plist, you add a dictionary for the key NSAppTransportSecurity. The dictionary should include one key, NSAllowsArbitraryLoads, and its value should be set to YES. This is what your application's Info.plist file should look like if you opt out of App Transport Security.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    ...
	<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSAllowsArbitraryLoads</key>
		<true/>
	</dict>
	...
</dict>
</plist>

Opt Out With Exceptions

There is a fourth option in which your application opts out of App Transport Security, but defines a number of exceptions. This is useful if your application fetches data from a range of servers you don't control, but also talks to an API you maintain. In that case, you specify in your application's Info.plist that arbitrary loads are allowed, but you also define one or more exceptions for which App Transport Security is enabled. This is what the Info.plist could look like.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    ...
	<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSAllowsArbitraryLoads</key>
		<true/>
		<key>NSExceptionDomains</key>
		<dict>
			<key>api.tutsplus.com</key>
			<dict>
				<key>NSExceptionAllowsInsecureHTTPLoads</key>
				<false/>
			</dict>
		</dict>
	</dict>
	...
</dict>
</plist>

Timing

Apple has emphasized that applications automatically opt in to App Transport Security if they are built against iOS 9 or OS X El Capitan. This means that you won't have to make any changes to your applications as long as you build them against iOS 8 or OS X Yosemite.

Based on previous releases of iOS and OS X, however, we have learned that Apple requires developers to build their applications against the latest SDK fairly soon after their official release. In other words, even though you won't have to comply with App Transport Security when iOS 9 and OS X El Capitan are released later this year, it is very likely that Apple will require developers to build against the latest SDK in the first or second quarter of 2016. I therefore recommend that you investigate how App Transport Security will impact your applications sooner rather than later.

Conclusion

I hope this article has made it clear that App Transport Security is not something your applications can adopt some day. It's similar to Apple's requirement for 64-bit support not too long ago. Unless your applications only talk to servers over HTTPS that comply with the ATS requirements, you need to invest some time to investigate how App Transport Security will impact your applications. Apple's technote about App Transport Security can help you with this.