1. アーキテクチャ・設計・脅威モデリング要件
1.1. MSTG-ARCH-1
アプリのすべてのコンポーネントを把握し、それらが必要とされている。
1.1.1. コンポーネント
アプリのすべてのコンポーネントを把握して、不要なコンポーネントを削除すること。
主なコンポーネントの種類は以下の通り。
コンテント
Charts
Image views
Text views
Web views
レイアウトと組織
Boxes
Collections
Column views
Disclosure Controls
Labels
Lists and tables
Lockups
Outline views
Split views
Tab views
メニューとアクション
Activity views
Buttons
Context menus
Dock menus
Edit menus
Menus
Pop-up buttons
Pull-down buttons
Toolbars
ナビゲーションと検索
Navigation bars
Path controls
Search fields
Sidebars
Tab bars
Token fields
プレゼンテーション
Action sheets
Alerts
Page controls
Panels
Popovers
Scroll views
Sheets
Windows
選択と入力
Color wells
Combo boxes
Digit entry views
Image wells
Onscreen keyboards
Pickers
Segmented controls
Sliders
Steppers
Text fields
Toggles
状態
Activity rings
Gauges
Progress indicators
Rating indicators
システム
Complications
Home Screen quick actions
Live Activities
The menu bar
Notifications
Status bars
Top Shelf
Watch faces
Widgets
1.2. MSTG-ARCH-2
セキュリティコントロールはクライアント側だけではなくそれぞれのリモートエンドポイントで実施されている。
1.2.1. 認証・認可情報の改竄
1.2.1.1. 適切な認証対応
認証・認可のテストを行う場合は、以下の手順で行う。
アプリが使用する追加の認証要素を特定する。
重要な機能を提供するすべてのエンドポイントを特定する。
すべてのサーバ側エンドポイントにおいて、追加要素が厳密に実施されていることを確認する。
認証バイパスの脆弱性は、サーバ上で認証状態が一貫して実施されておらず、クライアントが認証状態を改ざんできる場合に存在する。 バックエンドサービスは、モバイルクライアントからのリクエストを処理している間、リソースがリクエストされるたびに、ユーザがログインしているか、認可されているかを確認し、一貫した認可チェックを実施する必要がある。
OWASP Web Testing Guide の次の例を検討してください。 この例では、Web リソースは URL を介してアクセスされ、認証状態は GET パラメータを介して渡される。
http://www.site.com/page.asp?authenticated=no
クライアントは、リクエストと共に送られる GET パラメータを任意に変更することができる。
クライアントが単に authenticated パラメータの値を "yes" に変更することを妨げるものはなにもなく、効果的に認証をバイパスすることができてしまう。
これはおそらく実際には見られない単純な例だが、プログラマは認証状態を維持するために Cookie のような「隠れた」クライアント側パラメータに依存することがある。このようなパラメータは改ざんできないと想定している。例えば、Nortel Contact Center Manager における次のような典型的な脆弱性が考えられる。 Nortel のアプライアンスの管理 Web アプリケーションは、cookie の「isAdmin」に依存して、ログインしたユーザに管理権限を付与する必要があるかどうかを判断していた。 その結果、以下のようにクッキーの値を設定するだけで、管理者権限を取得することが可能であった。
isAdmin=True
セキュリティの専門家は、以前はセッションベースの認証を使用し、サーバ上でのみセッションデータを維持することを推奨していた。これにより、クライアント側でセッションの状態が改ざんされることを防ぐことができる。しかし、セッションベースの認証の代わりにステートレス認証を使用する要点は、サーバ上にセッションの状態を持たないことである。代わり、状態はクライアント側のトークンに保存され、リクエストごとに送信される。この場合、isAdmin のようなクライアント側のパラメータを見ることは、全く問題ない。
改ざんを防ぐために、クライアント側のトークンには暗号署名が付加されている。もちろん、うまくいかないこともあり、一般的なステートレス認証の実装は攻撃に対して脆弱である。例えば、いくつかの JSON Web Token(JWT) 実装の署名検証は、署名タイプを「None」に設定することで無効化することが可能である。この攻撃については、「Testing JSON Web Token」の章で詳しく説明する。
参考資料
1.2.2. インジェクション欠陥
インジェクションの欠陥は、ユーザ入力がバックエンドのクエリやコマンドに挿入されたときに発生するセキュリティ上の脆弱性のことである。メタ文字を挿入することで、攻撃者は、コマンドやクエリの一部として誤って解釈される悪意のあるコードを実行できる。 例えば、SQL クエリを操作することで、攻撃者は任意のデータベースレコードを取得したり、バックエンドのデータベースの内容を操作したりすることができる。
このクラスの脆弱性は、サーバ側の Web サービスに最も多く存在する。モバイルアプリにも悪用可能な例があるが、発生頻度は低く、攻撃対象領域も小さくなっている。
例えば、アプリがローカルの SQLite データベースにクエリを実行する場合、そのようなデータベースは通常、機密データを保存しない（開発者が基本的なセキュリティプラクティスに従っている場合）。 このため、SQL インジェクションは攻撃ベクトルとしてふさわしくない。 それにもかかわらず、インジェクションの脆弱性が悪用されることもあるため、適切な入力検証はプログラマにとって必要なベストプラクティスであると言える。
参考資料
ルールブック
1.2.2.1. SQLインジェクション
SQL インジェクション攻撃は、あらかじめ定義された SQL コマンドの構文を模倣して、入力データに SQL コマンドを統合する。 SQL インジェクション攻撃が成功すると、攻撃者は、サーバから付与された権限に応じて、データベースへの読み取りまたは書き込みが可能になり、管理コマンドを実行できる可能性がある。
Android と iOS のアプリは、ローカルデータストレージを制御および整理する手段として SQLite データベースを使用する。例えば、Android アプリが、ローカルデータベースにユーザ情報を保存して、ローカルユーザ認証を処理しているとする（例のために見過ごしている不適切なプログラミング手法である）。ログイン時に、アプリはデータベースにクエリを実行し、ユーザが入力したユーザ名とパスワードを使用してレコードを検索する。
SQLiteDatabase db;
String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password +"'";
Cursor c = db.rawQuery( sql, null );
return c.getCount() != 0;
さらに、攻撃者が「ユーザ名」と「パスワード」の欄に以下の値を入力したとする。
username = 1' or '1' = '1
password = 1' or '1' = '1
これにより、以下のようなクエリが発生する。
SELECT * FROM users WHERE username='1' OR '1' = '1' AND Password='1' OR '1' = '1'
条件 '1' = '1' は常に true と評価されるため、このクエリはデータベース内のすべてのレコードを返し、有効なユーザ アカウントが入力されていなくても、ログイン関数は true を返す。 Ostorlab は、この SQL インジェクションのペイロードを使用して、adbを使用して Yahoo's weather mobile application のソートパラメータを悪用した。
Mark Woods 氏は、QNAP NAS ストレージ・アプライアンス上で動作する「 Qnotes 」および「 Qget 」 Android アプリ内で、クライアント側 SQL インジェクションのもう1つの実例を発見した。これらのアプリは、SQL インジェクションに対して脆弱なコンテンツプロバイダをエクスポートし、攻撃者が NAS デバイスの認証情報を取得することを可能にする。この問題の詳細な説明は、 Nettitude Blog にある。
参考資料
1.2.2.2. XMLインジェクション
XML インジェクション攻撃では、攻撃者は XML メタ文字を挿入して XML コンテンツを構造的に変更する。 これは、XML ベースのアプリケーションまたはサービスのロジックを危険にさらすだけでなく、コンテンツを処理するXMLパーサーの操作を攻撃者が悪用できる可能性もある。
この攻撃の一般的な変種として、 XML eXternal Entity (XXE) がある。攻撃者は、URI を含む外部エンティティ定義を入力 XML に挿入する。XMLパーサーは、解析中に URI で指定されたリソースにアクセスし、攻撃者が定義したエンティティを展開する。
解析アプリケーションの完全性は、最終的に攻撃者の与えられる機能を決定し、悪意のあるユーザは次のいずれか（あるいはすべて） を行うことができる。ローカルファイルへのアクセス、任意のホストとポートへの HTTP リクエストの誘因、クロスサイトリクエストフォージェリ（ CSRF ）攻撃の起動、サービス拒否状態の誘因。 OWASP ウェブテストガイドには、 XXE に関する以下の例がある。
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>
この例では、ローカルファイル /dev/random が開かれ、そこで無限のバイトストリームが返されるため、サービス拒否が引き起こされる可能性がある。
現在のアプリ開発のトレンドは、XML が一般的でなくなってきているため、ほとんどが REST/JSON ベースのサービスに焦点を当てている。しかし、まれにユーザが提供したコンテンツや信頼できないコンテンツを使用して XML クエリを作成した場合、iOS の NSXMLParser などのローカル XML パーサーによって解釈される可能性がある。そのため、入力は常に検証する必要があり、メタ文字はエスケープする必要がある。
参考資料
ルールブック
1.2.2.3. インジェクション攻撃ベクトル
モバイルアプリの攻撃対象は、一般的な Web アプリケーションやネットワークアプリケーションとは全く異なる。モバイルアプリは、ネットワーク上にサービスを公開することがあまりなく、アプリのユーザインターフェース上で実行可能な攻撃ベクトルは稀である。 アプリに対するインジェクション攻撃は、プロセス間通信（ IPC ）インターフェースを介して発生する可能性が最も高く、悪意のあるアプリがデバイス上で実行されている別のアプリを攻撃することがある。
潜在的な脆弱性を見つけるには、まず次のどちらかを行う。
信頼できない入力の可能性のあるエントリポイントを特定し、その場所からトレースして、宛先に潜在的な脆弱性のある関数が含まれているかどうかを確認する。
既知の危険なライブラリ/API 呼び出し (SQL クエリなど) を特定し、未チェックの入力がそれぞれのクエリと正常に連携しているかどうかを確認する。
手動のセキュリティ レビューでは、両方の手法を組み合わせて使用する必要がある。 一般に、信頼できない入力は、次のチャネルを通じてモバイル アプリに侵入する。
IPCコール
カスタムURLスキーム
QRコード
Bluetooth、NFCなどで受信した入力データ
ペーストボード
ユーザインターフェース
以下のベスト プラクティスに従っていることを確認する。
信頼できない入力は、許容値のリストを使用して型チェックや検証を行う。
データベースクエリを実行するときは、変数バインディング (つまり、パラメータ化されたクエリ) を使用する prepared ステートメントが使用される。 prepared ステートメントが定義されている場合、ユーザ提供のデータと SQL コードは自動的に分離される。
XML データを解析するときは、XXE 攻撃を防ぐために、パーサーアプリケーションが外部エンティティの解決を拒否するように構成されていることを確認する。
X.509 形式の証明書データを扱う場合は、安全なパーサーが使用されていることを確認する。 例えば、バージョン 1.6 未満の Bouncy Castle では、安全でないリフレクションによるリモートコード実行が可能である。
各モバイル OS の入力ソースや脆弱性の可能性のある API に関する詳細は、OS 固有のテストガイドで参照。
参考資料
ルールブック
1.2.3. ルールブック
1.2.3.1. 適切な入力検証を実施する（必須）
インジェクションの脆弱性が悪用されることもあるため、適切な入力検証はプログラマにとって必要なベストプラクティスであると言える。
下記は入力検証の一例。
正規表現チェック
長さ/サイズチェック
これに違反する場合、以下の可能性がある。
インジェクションの脆弱性が悪用される可能性がある。
1.2.3.2. 入力は常に検証する必要があり、メタ文字はエスケープする必要がある（必須）
ユーザが提供したコンテンツや信頼できないコンテンツを使用して XML クエリを作成した場合、ローカル XML パーサーによって XML メタ文字が XML コンテンツとして解釈される可能性がある。そのため、入力は常に検証する必要があり、メタ文字はエスケープする必要がある。
下記は入力検証の一例。
正規表現チェック
長さ/サイズチェック
下記はメタ文字の一例。
文字 |
項目名 |
エンティティ参照による表記 |
|---|---|---|
< |
右大なり |
< |
> |
左大なり |
> |
& |
アンパーサント |
& |
" |
ダブルクォーテーション |
" |
' |
シングルクォーテーション |
' |
これに違反する場合、以下の可能性がある。
ローカル XML パーサーによって XML メタ文字が XML コンテンツとして解釈される可能性がある。
1.2.3.3. 宛先に潜在的な脆弱性のある関数を含めない（必須）
信頼できない入力の可能性のあるエントリポイントを特定し、その場所からトレースして、宛先に潜在的な脆弱性のある関数（サードパーティ製の関数）が含まれているかどうかを確認する。
これに違反する場合、以下の可能性がある。
プロセス間通信（ IPC ）インターフェースを介して、悪意のあるアプリがデバイス上で実行されている別のアプリを攻撃する可能性がある。
1.2.3.4. 未チェックの入力がそれぞれのクエリと正常に連携している（必須）
既知の危険なライブラリ /API 呼び出し (SQL クエリなど) を特定し、未チェックの入力がそれぞれのクエリと正常に連携しているかどうかを確認する。 また、利用するライブラリ /API のリファレンスを確認し、非推奨でないことを確認する。
iOS API リファレンス：https://developer.apple.com/documentation/
これに違反する場合、以下の可能性がある。
プロセス間通信（ IPC ）インターフェースを介して、悪意のあるアプリがデバイス上で実行されている別のアプリを攻撃する可能性がある。
1.2.3.5. 信頼できない入力を確認する（必須）
一般に、信頼できない入力は、次のチャネルを通じてモバイルアプリに侵入するため、チャネルの利用箇所をソースコードから特定し確認する。
下記はチャネルの利用を特定するキーワードの一例。
IPCコール： NSXPCConnection, XPC Services
カスタムURLスキーム： deeplink, URL Schemes, identifier
QRコード： qr, camera
Bluetooth、NFCなどで受信した入力データ： MCNearbyServiceBrowser, MCNearbyServiceAdvertiser, Core Bluetooth
ペーストボード： UIPasteboard
ユーザインターフェース： UITextField
これに違反する場合、以下の可能性がある。
プロセス間通信（ IPC ）インターフェースを介して、悪意のあるアプリがデバイス上で実行されている別のアプリを攻撃する可能性がある。
1.2.3.6. パーサーアプリケーションは外部エンティティの解決を拒否するように構成する（必須）
XXE 攻撃を防ぐために、パーサーアプリケーションは外部エンティティの解決を拒否するように構成する必要がある。
XXE を防止する最も安全な方法は、常に DTD (外部エンティティ) を完全に無効にすることである。パーサーに応じて、メソッドは次のようになる。
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
DTD を無効にすると、パーサーは Billion Laughs などのサービス拒否 ( DOS ) 攻撃に対しても安全になる。 DTD を完全に無効にすることができない場合は、各パーサーに固有の方法で、外部エンティティと外部ドキュメントタイプの宣言を無効にする必要がある。
これに違反する場合、以下の可能性がある。
XXE 攻撃に対して脆弱となる。
参考資料
OWASP Cheat Sheet Series XML External Entity Prevention https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#general-guidance
1.2.3.7. X.509 形式の証明書データを利用する場合は安全なパーサーを使用する（必須）
X.509 形式の証明書データを扱う場合は、安全なパーサーを使用する。
下記は安全なパーサーの一例。
これに違反する場合、以下の可能性がある。
安全でないリフレクションによるリモートコード実行等、インジェクション攻撃に対して脆弱となる。
1.3. MSTG-ARCH-3
モバイルアプリと接続されるすべてのリモートサービスの高次のアーキテクチャが定義され、そのアーキテクチャにセキュリティが対応されている。
※リモートサービス側での対応に関する章であるため、本資料ではガイド記載を省略
1.4. MSTG-ARCH-4
モバイルアプリのコンテキストで機密とみなされるデータが明確に特定されている。
機密情報の分類は、業界や国によって異なる。さらに、組織は機密データに対して制限的な見方をしている場合があり、機密情報を明確に定義するデータ分類ポリシーを持っている場合がある。
データ分類ポリシーが利用できない場合は、一般的に機密と見なされる情報の次のリストを使用する。
参考資料
ルールブック
1.4.1. ユーザ認証情報
ユーザ認証情報 (資格情報、PIN など)。
1.4.2. 個人識別情報
個人情報の盗難に悪用される可能性のある個人識別情報 (PII): 社会保障番号、クレジット カード番号、銀行口座番号、健康情報。
1.4.3. デバイス識別子
個人を特定できるデバイス識別子。
1.4.4. 機密性高いデータ
侵害されると風評被害や金銭的コストにつながる機密性の高いデータ。
1.4.5. 保護が法的義務であるデータ
保護が法的義務であるデータ。
1.4.6. 技術データ
アプリ (またはその関連システム) によって生成され、他のデータまたはシステム自体を保護するために使用される技術データ (暗号化キーなど)。
1.4.7. ルールブック
1.4.7.1. データ分類ポリシーに従い、機密データを識別する（必須）
業界・国・組織で明確に定義されているデータ分類ポリシーに従い、機密データを識別する。データ分類ポリシーが利用できない場合は、一般的に機密と見なされる情報として以下のリストを使用する。
ユーザ認証情報（資格情報、 PIN など）
個人情報の盗難に悪用される可能性のある個人識別情報（ PII）：社会保障番号、クレジット カード番号、銀行口座番号、健康情報。
個人を特定できるデバイス識別子
機密性高いデータ：侵害されると風評被害や金銭的コストにつながる機密性の高いデータ。
保護が法的義務であるデータ
アプリ（またはその関連システム）によって生成され、他のデータまたはシステム自体を保護するために使用される技術データ（暗号化キーなど）。
「機密データ」の定義なしで機密データの漏洩を検出することは不可能な場合があるため、定義はテストを開始する前に決定する必要がある。
これに違反する場合、以下の可能性がある。
ペネトレーションテストの結果から侵害される可能性のある機密データを機密データとして認識できず、リスクとして把握・対策出来ない可能性がある。
1.5. MSTG-ARCH-12
アプリはプライバシーに関する法律および規制に準拠している。
1.5.1. プライバシーに関する一般的な法律および規則
参考資料
1.5.1.1. 個人情報・プライバシー
個人情報を扱っている場合、GDPR,個人情報保護法に準拠していること。
1.5.1.2. 医療データ
医療データを扱っている場合、HIPAA,HITECHに準拠していること。
1.5.1.3. 金融情報
クレジットカード情報
クレジットカード情報を扱っている場合、PCI DSSに準拠していること。
1.5.2. プライバシーに関する App Store での規則
Appleのエコシステムにおいて、ユーザのプライバシーの保護は最優先に扱われる。個人のデータは慎重に扱い、ユーザの期待に応えることはもちろん、プライバシーのベストプラクティス、すべての適用法および「Apple Developer Program使用許諾契約」の規約に準拠することが求められる。以下に具体例を記載する。
参考資料
1.5.2.1. データの収集および保存
プライバシーポリシー すべてのAppには、App Store Connectのメタデータフィールドと各App内にアクセスしやすい形で、プライバシーポリシーへのリンクを必ず含める必要がある。プライバシーポリシーはわかりやすく明確なものである必要がある。
App/サービスが収集するデータの種類（該当する場合）、データの収集方法、データの用途はすべて明確に提示すること。
本ガイドラインに準拠して、Appのユーザデータをサードパーティ（分析ツール、広告ネットワーク、サードパーティ製のSDK、その他ユーザデータにアクセスできる親会社、子会社、その他の関連組織）と共有する場合は、そのサードパーティがAppのプライバシーポリシーで定める内容や本ガイドラインの要求事項と同一、あるいは同等のレベルでユーザのデータを保護していることを確認する必要がある。
データ保存/削除のポリシーと、ユーザが同意を無効にする方法やユーザデータの削除をリクエストする方法を記載する必要がある。
許可 ユーザデータや使用状況に関するデータを収集するAppでは、収集するデータが収集の時点またはその直後の時点で匿名であると考えられる場合でも、そのデータ収集に関してユーザから同意を得る必要がある。有料の機能は、ユーザデータへのアクセスをユーザが許可することに応じるもの、またはそれを条件とすることはできない。また、Appでは、簡単にアクセスできるわかりやすい方法でユーザが同意を撤回できるようにする必要がある。必ず、目的文字列でデータの用途を明確かつ十分に説明すること。正当な利益のため、同意を得ることなくデータを収集するAppは、EU一般Data protection規則（GDPR）の規約、またはそれに類する制定法のすべての条項を遵守する必要がある。詳しくは、「許可のリクエスト」を確認すること。
必要最低限のデータ Appは、中心的な機能に関連するデータへのアクセスのみがリクエストされ、関連するタスクの実行に必要なデータのみが収集および使用されるものである必要がある。可能な場合、「写真」や「連絡先」といった保護されているリソースへの完全なアクセス権をリクエストする代わりに、プロセス外のピッカーやシェアシートを使用すること。
アクセス Appでは、ユーザのアクセス許可設定を尊重しなければならない。不要なデータアクセスに同意するようユーザを巧みに誘導したり、だましたり、強制したりすることはできない。たとえば、ソーシャルネットワークに写真を投稿できるAppで、マイクへのアクセスに同意しなければ写真をアップロードできない仕様とすることは許可されない。可能であれば、アクセスに同意しないユーザ向けに別の方法を用意すること。たとえば、位置情報の共有に同意しないユーザには、住所を手動で入力できる機能を用意することができる。
アカウントへのログイン アカウント情報をベースにした重要な機能を実装しているものでない限り、Appにログインせずに使用できるようにする。アカウントの作成に対応したAppの場合は、App内でアカウントの削除もできるようにする必要がある。Appの中心的な機能に直接関連する場合、または法律で要求される場合を除き、Appを動作させるためにユーザの個人情報の入力を要求することは許可されない。Appの中心的な機能が特定のソーシャルネットワーク（Facebook、WeChat、Weibo、Twitterなど）に関連するものでない場合は、ログインや別のメカニズムを介さずに使用できるようにする必要がある。基本的なプロフィール情報の取得、ソーシャルネットワークへの公開、Appを利用するよう友達を招待することは、Appの中心的な機能とはみなされない。また、ソーシャルネットワークの認証情報や、Appとソーシャルネットワーク間のデータアクセスをApp内で無効にできるメカニズムを用意する必要があります。Appでは、ソーシャルネットワークの認証情報やトークンをデバイスの外部に保存することはできない。そうした認証情報やトークンは、Appの使用中に、Appから直接ソーシャルネットワークに接続するときにのみ使用することができる。
Appを利用して密かにユーザのパスワードやその他のプライベートデータを取得するデベロッパは、Apple Developer Programから除名される。
ユーザに情報を視覚的に提示する際は、必ずSafariViewControllerを使用する必要がある。SafariViewControllerを非表示にしたり、別のビューやレイヤーで隠したりすることは許可されない。また、SafariViewControllerを使用して、ユーザの認知や同意なしにAppでユーザのトラッキングを行うことは許可されない。
ユーザ以外のソースから取得した個人情報、またはユーザの明示的な同意なしに取得された個人情報を収集するAppは、その情報が公開データベースからのものであったとしても、App Storeでは許可されない。
規制の多い分野（バンキングや金融サービス、ヘルスケア、ギャンブル、合法大麻の使用、航空旅行など）でのサービスを提供するApp、機密性の高いユーザ情報を必要とするAppは、個人のデベロッパではなく、そうしたサービスを提供する法人によって提出される必要がある。大麻の合法的な販売を促進するためのAppは、それが合法とみなされる法的管轄地域でのみ利用できるよう、地域制限を設定する必要がある。
Appは、ユーザの基本的な連絡先情報（たとえば名前やメールアドレスなど）の共有がユーザの任意の選択であり、いかなる機能やサービスの提供もこれらの情報の共有を条件にしておらず、本ガイドラインのその他の規定（子どもからの情報収集に関する制限を含む）にすべて遵守するものである限り、これらの情報をユーザにリクエストすることができる。
参考資料
1.5.2.2. データの使用と共有
法律で許可されているものでない限り、事前にユーザの許可を取らずに、ユーザの個人データを使用、送信、共有することはできない。使用する場合は、どこでどのようにデータを使用するかに関する情報をユーザが確認できる手段を提供する必要がある。Appで収集したデータは、Appの改善や、（「Apple Developer Program使用許諾契約」に準拠した）広告の提示といった目的でのみサードパーティと共有することができる。ユーザアクティビティをトラッキングするには、App Tracking Transparency APIを介して、ユーザの明示的な許可を得る必要がある。トラッキングについて、詳しくはこちらを確認すること。ユーザの同意なしに、またはプライバシー関連の法令を遵守せずにユーザデータを共有するAppはApp Storeから削除される。さらに、デベロッパはApple Developer Programから除名される場合がある。
法律で明示的に許可されている場合を除き、特定の目的のために収集されたデータを、ユーザの同意をあらためて取ることなく、別の目的に使用することはできない。
Appで収集したデータに基づき、密かにユーザプロファイルを構築することは許可されない。また、Appleから提供されたAPIで収集したデータ、「匿名化」されたデータ、「集積」されたデータ、または個人を識別できないその他の方法で収集されると説明されたデータに基づいて、ユーザの識別やユーザプロファイルの再構築を行おうとしたり、助長したり、それを他者に促したりすることは許可されない。
「連絡先」、「写真」、ユーザデータにアクセスするその他のAPIから収集した情報を使用して、自身での使用またはサードパーティに販売したり配信したりすることを目的とした連絡先データベースを構築することは許可されない。また、分析や広告/マーケティングを目的として、ユーザのデバイスに他にどのようなAppがインストールされているかに関する情報を収集することも許可されない。
ユーザの「連絡先」や「写真」で収集した情報を使用して、第三者に連絡を取ることは許可されない。ただし、ユーザ本人が明示的かつ個別にリクエストする場合はこの限りではない。「すべて選択」のオプションを用意したり、デフォルトですべての連絡先が選択される仕様にしたりすることは許可されない。メッセージを送信する前に、どのようなメッセージが受信者に表示されるかをユーザに明確に伝える必要がある（メッセージの内容や、表示される送信者情報など）。
HomeKit API、HealthKit、Clinical Health Records API、MovementDisorder API、ClassKit、または深度測定ツールや（ARKit、Camera API、Photo APIなどの）フェイスマッピングツールで収集したデータを、サードパーティが行うものを含めて、マーケティング、広告、またはユーザベースのデータマイニングに使用することは許可されない。CallKit、HealthKit、ClassKit、ARKitの実装におけるベストプラクティスについて詳しくは、リンク先を確認すること。
Apple Payを使用するAppでは、商品またはサービスの配信を円滑化または向上させる目的でのみ、Apple Payを通して取得したユーザデータをサードパーティと共有することができる。
参考資料
1.5.2.3. 健康および健康に関する調査
健康、フィットネス、医療データは特に慎重に扱う必要があり、ユーザの個人情報の保護を徹底するために、この分野のAppにはいくつかの追加ルールが適用される。
健康、フィットネス、医療に関する調査のために収集されたデータを、許可を得た健康管理の向上または健康調査のため以外の目的（広告、マーケティング、またはその他のユーザベースのデータマイニングなど）で、Appで使用またはサードパーティに公開することはできない。このデータは、Clinical Health Records API、HealthKit API、モーションとフィットネス、MovementDisorder API、健康関連の臨床調査から得られるデータなどを指す。ただし、ユーザに直接メリット（より低額な保険料など）を提供する場合には、メリットを提供する組織によってAppが提出されており、データがサードパーティと共有されない限り、ユーザの健康やフィットネスに関するデータをAppで使用することができる。その際、そのデバイスから収集される健康に関するデータについて具体的に明示する必要がある。
Appの使用によって、HealthKitまたはその他の健康調査Appや健康管理Appに虚偽のデータまたは誤ったデータが書き込まれないようにすること。また、個人の健康情報をiCloudに保存することはできない。
健康に関する臨床調査を実施するAppでは、参加者本人、未成年の場合は親または保護者から同意を得る必要がある。このような同意には、（a）調査の性質、目的、期間、（b）手順、患者へのリスクおよび利点、（c）データの機密性と扱いに関する情報（サードパーティとの共有を含む）、（d）患者が質問がある場合の連絡先、（e）辞退プロセスを含める必要がある。
健康関連の臨床調査を実施するAppは、独立した倫理審査委員会の適切な承認を得る必要がある。承認を受けた証拠を要望に応じて提示していただく必要がある。
参考資料
1.5.2.4. 子どもに関する配慮
多くの理由から、子どもの個人データを扱う場合は厳重な注意が求められる。児童オンラインプライバシー保護法（COPPA）やEU一般Data protection規則（GDPR）のような法律、およびその他の適用される規制または法律をすべて慎重に確認すること。
Appでは、これらの法律に準拠する目的でのみ生年月日や保護者の連絡先を要求することができる。ただし、ユーザの年齢に関係なく、そのAppがユーザにとって有益な機能またはエンターテイメントの価値を提供するものである必要がある。
主に子どもを対象としたAppには、サードパーティ製の分析機能またはサードパーティ製の広告を組み込むことはできない。これにより、子ども達にとって、より安全な環境を提供することができます。限られたケースでは、サードパーティ製の分析機能およびサードパーティ製の広告が許可される場合もある。この場合は、そのサービスがガイドラインの1.3で定められている規約に準拠することが条件となる。
さらに、「子ども向け」カテゴリのAppまたは未成年の個人情報（名前、住所、メールアドレス、位置情報、写真、ビデオ、絵、チャット対応の可否、その他の個人データ、上記の任意の組み合わせによる永続的識別子など）を収集、送信、共有する機能を持つAppにはプライバシーポリシーを設定し、子どものプライバシー保護法に関するすべての適用法に準拠する必要がある。「子ども向け」カテゴリのAppのペアレンタルゲートと、プライバシー保護法に基づく個人データ収集への保護者の同意は、通常同じではないことに注意すること。
ガイドラインの2.3.8で定められている点として、Appのメタデータに「子ども用」といった用語を使用できるのは、「子ども向け」カテゴリのAppに限られる。「子ども向け」カテゴリに属さないAppでは、App名、サブタイトル、アイコン、スクリーンショット、説明に、Appの主な対象ユーザが子どもであることを暗示的に表す用語を含めることはできない。
参考資料
1.5.2.5. 位置情報サービス
Appで位置情報サービスを使用できるのは、位置情報サービスがAppの機能またはサービスと直接関連する場合のみである。位置情報ベースのAPIは、救急サービスまたは自動車、飛行機、その他デバイスの自律制御のために使用することはできない。ただし、軽量のドローンや玩具などの小型デバイス、またはリモートコントロールの自動車警報システムなどは除く。位置情報を収集、送信、使用する際は、事前にユーザに通知し、同意を得る必要がある。Appで位置情報サービスを使用する場合は、Appにおけるこのサービスの目的を説明する必要がある。説明に関するベストプラクティスについては、「Human Interface Guidelines」を参照すること。
参考資料
1.5.3. 知的財産に関する App Store での規則
Appには自分で作成したコンテンツ、または使用許可を取得したコンテンツのみを使用すること。許可なくコンテンツを使用した場合はAppを削除する。もちろん、他のデベロッパが他者の作品を許可なく使用した場合はそのAppが削除される。ご自分の知的財産権がApp Storeの他のデベロッパに侵害されているおそれがある場合は、Webフォームから申し立てを行うこと。国や地域によって法律は異なりますが、少なくとも以下の各項に留意する必要がある。
全般 商標、著作権取得済みの作品、特許取得済みのアイデアなどの保護されたサードパーティ製の素材をAppで許可なく使用することはできない。また、誤解を招く、虚偽の、または模倣の描写、名前、メタデータをAppバンドルやデベロッパ名に含めることは許可されない。Appは、知的財産権およびその他の関連する権利を所有する、またはそのライセンスを受けている個人または法人によって提出される必要がある。
サードパーティのサイトおよびサービス Appがサードパーティのサービスのコンテンツを使用、アクセス、または表示する場合、あるいはそのコンテンツへのアクセスを収益化する場合、当該サービスの利用規約に従って特別の許可を得る必要がある。また、要望に応じて承認書類を提示していただく必要がある。
オーディオおよびビデオのダウンロード Appを使って違法なファイル共有を助長したり、コンテンツの供給元（Apple Music、YouTube、SoundCloud、Vimeoなど）の明示的な承認を得ることなく、そのコンテンツを保存、変換、またはダウンロードする機能をAppに搭載したりすることはできない。オーディオおよびビデオコンテンツのストリーミングも利用規約に違反する可能性があるため、Appでこれらのサービスにアクセスする前に必ず確認すること。要望に応じて書類を提出していただく必要がある。
Appleの承認 AppleがAppの開発元またはサプライヤーであると示唆または暗示することは許可されない。また、AppleがAppの品質または機能に関して推奨していると示唆または暗示しないこと。Appが「スタッフのおすすめ」に選ばれた場合、バッジが自動的に適用される。
Apple製品 既存のApple製品、既存のインターフェース（Finderなど）、既存のApp（App Store、iTunes Store、メッセージなど）、Appleの既存広告などとの混同を招くような、類似したAppを開発することは許可されない。サードパーティ製のキーボードやステッカーパックを含め、AppやExtensionにAppleの絵文字を含めることはできない。iTunesとApple Musicの音楽プレビューを娯楽的な目的で（フォトコラージュのBGM、ゲームのサウンドトラックなど）、またはその他の承認されていない目的で使用することは許可されない。iTunesやApple Musicの音楽プレビューを使用する場合は、iTunesやApple Musicの該当曲のリンクを表示する必要がある。Appでアクティビティリングを表示する場合は、アクティビティコントロールに類似する方法で、ムーブ、エクササイズ、スタンドのデータを表示することはできない。アクティビティリングの使用に関して詳しくは、「Human Interface Guidelines」を参照すること。AppでApple Weatherのデータを表示する場合は、WeatherKitドキュメントのアトリビューション要件に従う必要がある。
参考資料