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, Basis DSP uses each ad's SSL Status to determine if the ad is ATS compliant:
- Ads marked safe will bid on ATS inventory.
- Ads not marked safe will not bid on ATS inventory.
As you create new ads that use impression trackers, mark your ads safe if all impression trackers are ATS compliant.
Ads with creatives that are hosted by Basis 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.
Visit the preview page for the ad. If it's a VAST ad, click Play. Then, open Chrome's Developer Tools by selecting the Chrome menu (usually, the right-most icon to the right of the address bar)... > More Tools.. > Developer Tools. Select the Sources tab. This shows all of 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), it is necessary to click to expand to see the list of resources requested inside the IFRAME.
Gather the list of servers that the ad has called and 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.
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.
macOS comes with a utility that can perform ATS diagnostics. To use it, open Terminal and enter
nscurl --ats-diagnostics https://<domain name>
nscurl --ats-diagnostics https://cdn01.basis.net
The output will look something like this:
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
(additional output omitted for brevity)
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.