Two-thirds of iOS apps don’t use App Transport Security

Most iOS apps don’t take advantage of App Transport Security​ (ATS), a networking security feature offered by Apple that ensures encrypted connections between apps and the servers they communicate with.

The main reason, it seems, might be interrupted ad delivery.

What is App Transport Security?

“On Apple platforms, a networking security feature called App Transport Security (ATS) is available to apps and app extensions, and is enabled by default. It improves privacy and data integrity by ensuring your app’s network connections employ only industry-standard protocols and ciphers without known weaknesses. This helps instill user trust that your app does not accidentally leak transmitted data to malicious parties,” Apple’s documentation explains.

ATS was introduced as an optional feature in late 2015, with iOS 9.0 and OS X 10.11. Initially, developers had only the option to completely disable or enable it, but from iOS 10 on, more granular options were made available so they were able to set a global ATS configuration (either on or off) and then make exceptions for specific functions within the app.

Unfortunately, though, this granularity did not spur wide ATS adoption. As Wandera researchers have recently discovered after analyzing 30,000 iOS apps most commonly used by employees, nearly 68 percent have ATS disabled globally and don’t set any granular exceptions for specific functions (but might have exceptions for domains).

“Only 5.3% of apps use the new more granular keys to disable ATS, e.g. for media only, while most apps stick with disabling ATS completely for all communication,” they noted, but acknowledged that disabled ATS does not necessarily mean all communications are unencrypted. “It just means that system safeguards are disabled and hence there is much more room for error.”

The reasons for low adoption

Apple had planned to force all iOS developers to use ATS by 2017 but later dropped the requirement.

“The App Review Guidelines currently state that developers need to supply a justification for disabling ATS. But according to multiple sources, as well as our own research, it seems the justification does not need to be a strong one and, in most cases, developers are successfully disabling ATS,” the researchers noted.

“App developers may have good reasons for disabling ATS. Apps talk to third-party advertising, market research, analytics and file hosting services and these external services may not support HTTPS connections. Advertising networks such as ​MoPub​ and ​Google AdMob​ recommend disabling ATS completely to ensure ads are loaded correctly.”

It’s no surprise, then, that they also found that paid apps have ATS globally enabled more often than free apps (45.9% vs 26.2%, respectively).

Finance apps are most likely to have ATS enabled (40.4%), followed by health and fitness, utilities, and photo and video apps. News apps are highly unlikely to have it enabled (9%).

Another interesting insight gained from the research is that some developers seem confused about the various options: 9.2% of the analyzed apps have ATS disabled globally AND exceptions for domains that require ATS to be disabled.

“Perhaps the reason many developers disable ATS, despite Apple’s efforts, is because they don’t actually understand how it works due to its complexity,” the researchers noted.

“Or maybe they are taking the easy way out by just submitting all the domains their apps need as exceptions to avoid any potential interruptions to the end-user experience due to incompatibility with servers. The alternative route would be checking that each domain supports HTTPS and only making exceptions for those that do not. Many developers are under pressure to increase speed to market and remove unnecessary costs, so it’s easy to see why they would want to take shortcuts like blanket ATS exceptions.”

In any case, developers cannot and should not be wholly responsible for the success or failure of ATS.

“Web service operators also need to become part of the solution. They can’t keep supporting unencrypted content when OS vendors like Apple are trying to move toward total encryption. Web service operators should be supporting HTTPS and encouraging developers to use secure connections,” the researchers concluded.