The ATS (App Transport Security) proposed by WWDC 15 is an important way for Apple to advance the security of network communications. In IOS 9 and OS X 10.11, network access that is not HTTPS is forbidden by default. Of course, because such propulsion has a very wide impact, as a buffer, we can add a NSAppTransportSecurity
dictionary to info.plist and set it to NSAllowsArbitraryLoads
YES
disable ATS. I believe everyone has been very familiar with this, because I also maintained a number of network-related frameworks, so I also prepared a little foot to shut down ATS quickly.
However, in WWDC 16, Apple said it would continue to tighten access restrictions on normal HTTP in IOS 10 and MacOS 10.12. From January 1, 2017 onwards, all new submission apps are not allowed NSAllowsArbitraryLoads
to bypass ATS restrictions by default, that is, we'd better make sure that all of the app's network requests are encrypted by HTTPS, otherwise you may have trouble applying auditing.
Now (2016-11-28), the relevant provisions and several facts in this regard are as follows:
- By default, your app can access HTTPS content that is strong enough to encrypt (TLS v1.2 above, AES-128 and SHA-2, and ECDHC, and so on). This is valid for all network requests, including
NSURLSession
streaming media accessed through avfoundation, UIWebView
and WKWebView
so on.
- You can still add it to
NSAllowsArbitraryLoads
YES
disable ATS completely, but if you do, you need to explain when you submit your app and why you need to access non-HTTPS content. In general, this option can be easily and rudely turned on, and apps that can't find a valid reason will be hard to pass.
- It should be
NSAllowsArbitraryLoads
NSExceptionDomains
relatively easy to audit by setting the domain name to open HTTP, rather than using all HTTP content to open it, and choose to use it for a specific domain name NSExceptionAllowsInsecureHTTPLoads
. "The domain name that needs to be accessed is a third-party server, and they do not have HTTPS correspondence" is an optional reason to audit, but this should only be for a specific domain name, not full open. If you are accessing your own server, this may not be the case.
- For web browsing and video playback behavior, new and keys are added to IOS
NSAllowsArbitraryLoadsInWebContent
10 NSAllowsArbitraryLoadsForMedia
. By setting them up YES
, you can make online videos in your app UIWebView
, WKWebView
or using them, AVFoundation
not restricted by ATS. Although it still needs to be explained at the time of review, this should be the preferred choice for most apps that use the relevant features. The bad news is that this key doesn't work in IOS 9.
Summing up is the following two points:
- for API requests, it is basically necessary to use HTTPS, especially if you can manage the server yourself. May need the back end of the classmate to upgrade to HTTPS as soon as possible (although the words are used let's Encrypt, I have a personal blog enabled HTTPS, as the API user server, not open https really a bit justified). If you are using third-party APIs and they do not provide HTTPS support, you need to add them in
nsexceptiondomains
.
- If your app only supports IOS 10, and you have the ability to freely enter a URL for browsing, or an online video audio playback function, only add
Nsallowsarbitraryloadsinwebcontent
or/and Nsallowsarbitraryloadsformedia
, and replace the component with UIWebView
or Wkwebview
, and avfoundation
The player will be ready. If you still need to support IOS 9 and need access to Web pages and videos, you may only be able to turn on , nsallowsarbitraryloads
Then submit the instructions and see the Apple The auditor's face decided not to let it pass. In addition to Wkwebkit
, another option to access a Web page is to use sfsafariviewcontroller
. Because in fact Sfsafariviewcontroller
is an app-independent Safari process, so it's completely free of ATS restrictions.
- If you need to use the intranet, you can set up
nsallowslocalnetworking
without worrying about SSL connection issues.
In addition, when NSAllowsArbitraryLoads
and NSAllowsArbitraryLoadsInWebContent
or at the same time NSAllowsArbitraryLoadsForMedia
, depending on the system, the behavior of the performance will be different. Simply put, iOS 9 looks only NSAllowsArbitraryLoads
while iOS 10 takes precedence over InWebContent
ForMedia
the parts. In IOS 10, if the latter two exist, they are ignored in the relevant section, and NSAllowsArbitraryLoads
if they do not exist, NSAllowsArbitraryLoads
the settings are followed. It might be a little complicated, and I'll summarize here. Depending on the NSAppTransportSecurity
set conditions, the corresponding system version and the behavior of the request component can be used as a reference when you set up this dictionary (the table is used NSAllowsArbitraryLoadsInWebContent
as an example, NSAllowsArbitraryLoadsForMedia
but also the same):
ATS Settings |
Components to use |
IOS 9 HTTP |
IOS Ten HTTP |
Notes |
Nsallowsarbitraryloads:no |
WebView |
? |
? |
Default behavior |
|
Urlsession |
? |
? |
|
Nsallowsarbitraryloads:yes |
WebView |
? |
? |
Completely disable ATS |
|
Urlsession |
? |
? |
Justification required for review |
Nsallowsarbitraryloads:no & Nsallowsarbitraryloadsinwebcontent:yes |
WebView |
? |
? |
Disable ATS only for Web content |
|
Urlsession |
? |
? |
Ensure the security of the API |
Nsallowsarbitraryloads:no & Nsallowsarbitraryloadsinwebcontent:no |
WebView |
? |
? |
|
|
Urlsession |
? |
? |
|
Nsallowsarbitraryloads:yes & Nsallowsarbitraryloadsinwebcontent:no |
WebView |
? |
? |
Ignore nsallowsarbitraryloads settings when IOS 10,nsallowsarbitraryloadsinwebcontent is present |
|
Urlsession |
? |
? |
IOS 9 will continue to use Nsallowsarbitraryloads |
Nsallowsarbitraryloads:yes & Nsallowsarbitraryloadsinwebcontent:yes |
WebView |
? |
? |
Ignore nsallowsarbitraryloads settings when IOS 10,nsallowsarbitraryloadsinwebcontent is present |
|
Urlsession |
? |
? |
IOS 9 will continue to use Nsallowsarbitraryloads |
The list is based on the NSAppTransportSecurity
descriptions and sections of the Apple prerelease documentation NSAllowsArbitraryLoadsInWebContent
. If you find that this behavior has changed, or if there is a problem with the list above, please leave a message and I will correct it.
As a reference, the valid NSAppTransportSecurity
dictionary structure is also attached here:
NSAppTransportSecurity : Dictionary { Boolean NSAllowsArbitraryLoadsForMedia : Boolean NSAllowsArbitraryLoadsInWebContent : Boolean NSAllowsLocalNetworking : Boolean NSExceptionDomains : Dictionary { <domain-name-string> : Dictionary { NSIncludesSubdomains : Boolean NSExceptionAllowsInsecureHTTPLoads : Boolean NSExceptionMinimumTLSVersion : String NSExceptionRequiresForwardSecrecy : Boolean // Default value is YES NSRequiresCertificateTransparency : Boolean } }}
It has to be said that Apple's efforts to promote technological progress are evident in its current strong position. Whether it is a few days ago to force support IPV6, or now HTTPS, in fact, is not very easy to make decisions. Building a more secure environment for users may not only be something Apple can do unilaterally, but also a thing that requires developers to work with. As soon as possible to adapt to a more progressive and safe use of the way, it will be a winning thing.
Questions about ATS in IOS 10