In iOS 9+, Apple introduced App Transport Security (ATS), which requires that HTTP requests made within an app must be fully secure. With ATS, non-secure or inadequately secure requests are rejected by the operating system. Since ads are served in-app using HTTP/HTTPS, this affects the ability of ads to load in iOS apps.
Many iOS apps only accept ads that are ATS compliant. For an ad to be compliant, all of its components must be hosted on ATS-compliant servers, including:
- the creative image
- all impression trackers
As more apps (and more inventory) require ATS compliance, the DSP uses each ad's SSL Status to determine if the ad is ATS compliant:
- Ads marked Secure will bid on ATS inventory.
- Ads not marked Not Secure will not bid on ATS inventory.
As you create new ads that use impression trackers, mark your ads secure if all impression trackers are ATS compliant.
Ads with creatives that are hosted by the DSP (i.e. uploaded via our UI) and use no impression trackers are automatically marked secure.
Determining ATS Compliance
For an ad to be ATS compliant, all requests to all servers called in the ad must meet ATS requirements. The simplest approach to check this is to just ask any ad serving vendors or measurement vendors used by your ad. The vendors you use should be able to confirm that they're ATS compliant.
If you want to, you can directly check the ad. First, determine all the servers that the ad makes requests to. If unsure, one way to do this is using Chrome's Developer Tools.
To determine ATS Compliance in Chrome:
Go to the preview page for the ad. If it's a VAST ad, click Play.
Click the Chrome Main Menu icon, then select More Tools > Developer Tools.
Select the Sources tab. This tab shows all the resources that have been requested for the current page.
The rows with a cloud icon represent the servers.
If the ad uses IFRAMEs (represented by a window icon), click it to expand the list of resources requested inside the IFRAME.
Gather the list of servers that the ad has called.
Disregard these servers, as resources are requested for them as a part of the ad preview environment, not the ad itself:
Check any remaining servers using a tool like apptransport.info or nscurl. Review the sections below for more information.
Checking Servers with apptransport.info
where <domain name> is the domain of the server to be checked. For example:
After a time, an answer will come back that the server is or is not ATS compliant.
Chcking Servers with nscurl (macOS)
macOS comes with a utility that can perform ATS diagnostics. To use it, open Terminal, and then enter the following:
nscurl --ats-diagnostics https://<domain name>
nscurl --ats-diagnostics https://cdn01.basis.net
The output looks something like this (additional output omitted for brevity):
hostname:~ username$ nscurl --ats-diagnostics https://cdn01.basis.net
Starting ATS Diagnostics
Configuring ATS Info.plist keys and displaying the result of HTTPS loads to https://cdn01.basis.net.
A test will "PASS" if URLSession:task:didCompleteWithError: returns a nil error.
Use '--verbose' to view the ATS dictionaries used and to display the error received in URLSession:task:didCompleteWithError:.
Default ATS Secure Connection
ATS Default Connection
Result : PASS
There are many tests performed, but the important one is "ATS Default Connection". If the result is PASS, then the server is ATS compliant. Any other result means that the server is not ATS compliant.