App Transport Securityとネットワーク広告

新規広告開発部の松本です。

本日午前2時のAppleの発表イベントにて、iOS 9が9/16にリリースされる事が明らかになりましたね(GM版は本日リリース)。
このiOS 9には様々な機能追加がありますが、iOSアプリにネットワーク広告を設置されている方はApp Transport Security(以下ATS)に気をつける必要があります。

ATSとは

公式ドキュメントによると、

App Transport Security is a feature that improves the security of connections between an app and web services. The feature consists of default connection requirements that conform to best practices for secure connections. Apps can override this default behavior and turn off transport security.

Transport security is available on iOS 9.0 or later, and on OS X 10.11 and later.

とあります。
一言で言えば「デフォルトではAppleの推奨する設定のHTTPS通信を強制する」ということです。
詳しくは上記公式ドキュメントやWWDCのセッション動画(Safariのみ再生可、書き起こしはこちら)、Developers.IOの記事等を参照すると良いでしょう。また、弊社エンジニアのブログ記事も参考になります。

ATSとネットワーク広告

このようにiOSアプリおよび通信先のサーバの対応が強く求められているのですが、個々のiOSアプリ開発者だけではどうにもならない通信先もあったりします。
本稿ではその具体例としてネットワーク広告を挙げてみます。

ATSを有効にすると、ネットワーク広告が表示されなくなる可能性があります*1。 ですので、現在使用しているネットワーク広告がATS対応かどうかを調査し、非対応なのであれば「そのネットワーク広告の使用を諦める」か「ATSの設定を変更する」かを選択しなければいけません。

現在、各社SDKの状況は「既に対応済み」「まだ対応していないが対応予定」「アナウンスがないので問い合わせる必要がありそう」等様々ですが、オープンにアナウンスされている例としてGoogleMobileAds SDKを見てみます。

Google Ads Developerブログによると、

This change may need your action if you are developing with the Google Mobile Ads SDK and building an app against the iOS 9 SDK.

(中略)

While Google remains committed to industry-wide adoption of HTTPS, there isn’t always full compliance on third party ad networks and custom creative code served via our systems.

とあります。GoogleMobileAds SDKではまだATSに対応しきれていないため、このままでは広告を取得できなくなるようです。

また、

To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful. Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.

とあります。GoogleとしてもできるだけATSを無効にするのは避けて欲しいが、他に打つ手が無い場合、選択的にATSの設定を変更することを検討して欲しいようです。

(※ ちなみに上記ブログ中で画像とコード付きで示されている対策方法はATSを完全に無効にするため推奨されません。)

ATSの設定変更はInfo.plistに値を入力することで行います。 以降では、ATSを有効にするドメインだけを列挙する方法と、無効にするドメインだけを列挙する方法を記載します。

ATSを有効にするドメインだけを列挙する方法

NSAllowsArbitraryLoadsで例外を除く全てのドメインでATSを無効にします。
また、例外としてexample.comに対してのみNSExceptionAllowsInsecureHTTPLoadsNO, <false/>になっています。

選択的に有効化

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
        </dict>
    </dict>
</dict>

自社APIのエンドポイントはATS対応したいけれどATS非対応のネットワーク広告も使いたい・・・という場合は、この方法を取る必要があるようです。

ATSを無効にするドメインだけを列挙する方法

今回のネットワーク広告の件には関係ありませんが、選択的有効化の逆も記載しておきます。

ATSはデフォルトで有効なので、こちらはNSAllowsArbitraryLoadsのような指定がありません。
また、例外としてexample.comに対してのみNSExceptionAllowsInsecureHTTPLoadsYES, <true/>になっています。

選択的に無効化

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
        </dict>
    </dict>
</dict>

ATSを部分的に無効にして大丈夫なの?という話

これに関しては弊社エンジニアのブログ記事を参照したいと思います。

諸説あるとは思いますが、ATS を切ることそのものが危険な状態に繋がるわけではなく、こうしたものをあまり理解せずに切ってしまったり、切ったまま対応を考えないといったことが危険な状態を招くと考えています。

ATSの設定変更によりHTTPS化をサボる訳ではなく、常に自分のアプリの通信先に気を配り、最終的には全てのドメインでATSを有効にしても問題ない形になるよう努める必要がありますね。

また、ネットワーク広告に限らず、皆さんがiOSアプリからアクセス可能なエンドポイントを公開していましたら、ATS対応を検討すると皆さんも周りの人も幸せになれるかもしれません!

参考

*1:ATSはXcode 7以降でビルドしたアプリで有効になるため、Xcode 6を使っている場合は有効になりません。ですので、何もしていないからネットワーク広告が表示されなくなっちゃう!ということは(最後にアプリをリリースした時にXcode 6を使っていれば)ないはずです。