iOS ATS - How does it work, and how do so many apps ignore it

Question

This is a more general question/discussion, regarding App Transport Security. ATS ensures that all network traffic between an iPhone and the internet is done securely (i.e. HTTPS). This is really good in theory, except there are many websites that don't have HTTPS versions. Most of the reading I've done on the subject comes down to:

"Ok, that's not a problem, because our app only needs to talk wit our backend, where we can control the security"

But what if your app doesn't talk to one backend? What if you don't have that much control?

"My app does news aggregation from a variety of sources, which may or may not have HTTPS links, and I can't control wether or not they do"

For example, ESPN's public facing site doesn't have an HTTPS endpoint. If you go to https://espn.com it will redirect you to http://espn.com

Another common response to this problem is: "Ok, add espn to your ATS Exception Domains"

Even more general - How does an app like Facebook, which uses its own built-in browser, deal with the fact that people posting links in their timeline may or may not use HTTPS links? Surely they don't whitelist the entire internet in their info.plist

Any ideas? I know it's a fairly broad & open ended question, but I'm really trying to figure out whats the best way to comply with ATS and allow for a good surfing experience in an app.

Answer 1

Basically, you should handle this by enabling as few exceptions as possible for the needs of your app. Many of the answers here on SO guide developers to just disable ATS all together. That's bad for two reasons -

1. It likely decreases the security of your apps communications
2. At some point Apple will start enforcing the justification that they told developers about at WWDC 2016.

You are on the right track, though. If the app is accessing server base resources from servers that don't support HTTPS (or forward secrecy, or TLS 1.2), you should ad NSExceptionUrls for just the areas where they are lacking with respect to ATS. Again, don't disable all ATS for a URL if it supports TLS 1.2, but doesn't support forward secrecy. In that case, just add the exception for requiring forward secrecy. This will make a possible future justification with Apple much easier - "We don't control the server, or we can support forward secrecy, but we are still allowing ATS to protect app users for everything else.

As for unknown servers, such as servers that are specified by the user, you will likely have to disable ATS globally with the NSAllowsArbitraryLoads exception. Don't stop there, however. If you do connect to your own servers that are ATS compliant, you can then add a URL exception where you enable ATS for that URL. Again, this shows Apple that you are trying to enforce aTS protections wherever possible.

Finally, for specific content (such as web browsing), you can't necessarily control where your users go, so you can specify the NSAllowsArbitraryLoadsInWebContent exception to protect everything that isn't in an WKWebView or SFSafariViewController, while letting users browse to web sites that may not support all the ATS requirements.

So, long story short, try to leave ATS on for as much as possible, so that you best protect your users privacy / data, while still giving them the functionality they need. Taking that effort will certainly help when Apple starts asking for justification for your ATS exceptions.