2026.08.21

スマホアプリセキュリティ診断の進め方と費用

経営リスクナビ編集部

スマホアプリ診断（脆弱性診断）は、iOS/Androidアプリの企画・開発・運用を進める中で、端末側・通信・バックエンドまで含めて「どこに弱点があり、どこから直すべきか」を第三者視点で整理するための実務手段です。診断を後回しにすると、公開直前に指摘が出て修正・再テストの余裕がなくなったり、外注先管理や個人情報保護法20条（個人情報保護法第20条）の安全管理措置として説明しにくくなったりします。特に侵入テストは完了まで数カ月かかるため、調達・社内調整を含めて計画に織り込む前提が必要です。以下では、診断導入の判断材料として対象範囲・項目・進め方・見積りの見方を示します。

スマホアプリ診断の位置づけ
- 脆弱性診断との違いを整理する
- スマホアプリ特有のセキュリティリスク
診断対象と診断項目
iOSとAndroidの診断観点
- iOSで見る設定とアクセス制御
- Androidで見る権限とデータ管理
診断手法と実施タイミング
スマホアプリ診断の進め方
費用とベンダー選定
よくある質問
スマホアプリ診断への対応で次にすべきこと

スマホアプリ診断の位置づけ

脆弱性診断との違いを整理する

スマホアプリ診断は、アプリ／API／バックエンドを含む実装の弱点を洗い出し、修正優先度を付けて是正につなげるための脆弱性診断の一類型です。診断担当者（脆弱性診断士）はネットワーク、OS、ミドルウェア、アプリケーションがセキュアかどうかを検査し、診断結果を評価する役割だと整理されています。

一方のペネトレーションテスト（侵入テスト）は、攻撃者視点で実際に侵入できるかを試し、現状の対策が「攻撃の連鎖」に耐えるかを検証します。ペネトレーションテストは業務影響に配慮した範囲調整や事前準備が必要で、依頼から完了まで数カ月かかり、即時に実施できるものではない点を前提に計画します。

観点	脆弱性診断（スマホアプリ診断を含む）	ペネトレーションテスト
狙い	不備を広く見つけて是正し、全体の水準を底上げする	侵入経路が成立するかを攻撃者視点で検証する
深さ	既知・準既知の欠陥を中心に網羅的に確認する	特定の重要資産まで到達できるかを深掘りする
前提	診断結果の評価・優先度付けまで含めて運用に乗せる	調整・準備が多く、完了まで数カ月かかり得る

脆弱性診断とペネトレーションテストの違い

実務では、まず脆弱性診断で「修正すべき不備の棚卸し」と「再発防止の観点（設計・実装・設定の癖）」を掴み、重要領域について侵入テストで攻撃連鎖の有無を追加検証する、という順序だと社内説明が通しやすいです。

スマホアプリ特有のセキュリティリスク

スマホアプリは、利用者の手元（端末）に実行ファイルが配布され、端末側でデータ処理も行われるため、攻撃者が端末上で解析・改変を試みやすいという前提があります。Webアプリのように処理がサーバ側に閉じないため、端末が攻撃者の管理下に置かれ得ることを前提に設計・診断を組みます。

典型例は、配布物を逆コンパイルして内部実装を読み解くリバースエンジニアリングです。ここで暗号鍵の取り扱い、通信手順、デバッグ用ログの出力などが弱いと、なりすましや不正接続につながります。

また、端末の紛失・盗難だけでなく、利用者がフィッシングにより認証情報を入力してしまうリスクもモバイルでは現実的です。SMS（ショートメッセージサービス）を介した詐欺が横行し、大手宅配会社・クレジットカード会社・通信事業者・国・銀行などを装って偽サイトに誘導し、ID／パスワード／個人情報／クレジットカード番号の入力を促すとされています。

モバイル特有の前提として押さえる脅威

端末上の解析（逆コンパイル等）で通信仕様や秘密情報の取り扱い不備が露見するリスクがあります。
端末内のローカル保存（キャッシュ、DB、ログ）から認証トークン等が取得されるリスクがあります。
SMS経由のフィッシングでIDやパスワード等が窃取される前提で、認証・不正利用対策を設計する必要があります。
端末OSやアプリを最新状態に保つ運用が必須で、iOS/Androidは設計上の防御は強いものの脆弱性は発見され続けます。

個人データの漏えい等を防ぐために必要かつ適切な安全管理措置を講じる義務（個人情報保護法20条（個人情報保護法第20条））の観点でも、端末側・通信・サーバ側をまとめてリスク評価し、診断結果を是正計画に落とし込む位置づけが重要です。

診断対象と診断項目

診断対象はアプリ・API・サーバ

スマホアプリの「アプリ本体」だけを堅牢化しても、実際の攻撃はAPIやバックエンドの弱点に迂回します。そのため、診断設計はアプリ・API・サーバを一体のデータフローとして定義し、どこで認証され、どこで保存され、どこでログが残るかまで含めて確認します。

外部公開されるサーバや通信機器に対する脆弱性診断、ネットワーク環境診断、クラウド移行時の設定不備確認など、第三者によるチェックが安全性担保に重要だとされています。スマホアプリの場合も、アプリ単体ではなく、接続先（サーバ・クラウド・ネットワーク）まで含めて第三者チェックの射程を設計するのが実務的です。

実務で「対象に含める」と整理しやすい範囲

スマホアプリ本体（iOS/Android）と、端末内の保存領域（キャッシュ、ローカルDB、ログ）を対象にします。
API（認証・認可、入力検証、ID参照、レート制限等）を対象にします。
バックエンド（OS・ミドルウェア・アプリケーション）を対象にし、のとおりOSは最新の状態を維持できているかも含めて確認します。
クラウドを使う場合は「設定不備を作らない」を前提に、設定レビューも診断の対象に含めます。

診断項目は認証・通信・データ保護

診断項目は、(1)認証・認可、(2)通信、(3)データ保護の3本柱で整理すると、情シス・開発・法務で共通言語化しやすいです。

3本柱の確認観点（スマホアプリ診断）

認証・認可：セッション管理、トークン失効、権限チェック漏れ、アカウント管理（不要IDの削除等）を確認します。
通信：TLSの強制（サイトのSSL化の考え方をAPI通信にも適用）、証明書検証、改ざん耐性を確認します。
データ保護：端末内に個人情報・認証情報が平文で残らないこと、鍵がOSの保護領域（iOSキーチェーン、Androidキーストア等）で管理されることを確認します。

加えて、アプリ単体の設計・実装が良くても、運用で検知できなければ被害が拡大します。サーバ側でログが取得されていても「確認する術がない」「解析せず放置」が多いとされ、CPU・メモリ・ネットワークトラフィック等の異常値（閾値）を設定し、アラート通知する仕組みが有効だとされています。診断では、重大APIについて「ログが取れているか」だけでなく「閾値・通知・一次対応手順があるか」も確認対象にすると、結果が運用改善に直結します。

個人情報を扱うアプリで診断対象を広げる線引きはどこか

個人情報を扱うアプリでは、入力から通信、保存、表示、削除までのデータライフサイクルで「どこが漏れたら事故になるか」を基準に、診断範囲を定義します。個人データの漏えい等を防ぐために必要かつ適切な安全管理措置を求める規律（個人情報保護法20条（個人情報保護法第20条））に照らしても、範囲が曖昧だと、診断していても説明責任を果たしにくくなります。

内部からの情報事故対策として、スマホ・タブレットに対してMDM導入／アプリインストール制御、サーバ・ネットワークではログ取得と閾値設定などが挙げられています。個人情報を扱う場合は「アプリの脆弱性」だけでなく、端末管理や運用統制（MDM等）が弱点になっていないかも線引きに含めると、現実の事故形態に合います。

線引きの決め方（実務手順）

取り扱う情報を棚卸しし、個人情報・認証情報・決済情報など「漏えい時の影響が大きいデータ」を特定します。
データフロー（入力→端末内→通信→API→サーバ／クラウド→ログ→バックアップ）を図示し、保管場所と転送経路を洗い出します。
外部連携（SDK、決済、本人確認、分析基盤等）がある場合は、連携点を診断対象に含めます。
端末統制が必要な運用（社内利用アプリ等）の場合、MDMによるアプリインストール制御やリモートワイプ等の統制も確認対象に含めます。

iOSとAndroidの診断観点

iOSで見る設定とアクセス制御

iOSの診断では、OSが提供する保護機能が「有効化され、例外設定が過剰でないか」を中心に確認します。スマホOSは設計上のセキュリティレベルが高く、過度に恐れる必要はない一方で、のとおり脆弱性は発見され続けるため、継続的なアップデートを前提に、設定・実装・運用のズレを潰します。

iOSでの代表的な確認観点

安全な通信を強制する設定（ATS等）で、暗号化されない接続が不要に許可されていないか確認します。
キーチェーンのアクセス制御が適切で、認証情報や鍵素材が平文・不適切な領域に保存されていないか確認します。
脱獄端末等のリスク端末での動作制御（検知・制限）を、業務要件と両立する形で確認します。
OS・アプリを最新状態にする運用（アップデート適用）が回っているかも、診断結果の前提条件として確認します。

Androidで見る権限とデータ管理

Androidの診断では、権限（パーミッション）の最小化と、データ保存・鍵管理が「他アプリや端末状態の影響」を受けにくい形でできているかを確認します。

ネットワーク面の対策としてVPN機器のID／パスワードの複雑さや多要素認証、Wi‑Fiの通信暗号化などが挙げられています。Androidアプリでも、端末が不特定ネットワークにつながる前提に立つため、通信の暗号化だけでなく、認証・端末識別・不正利用検知（ログ・監視）を含めた設計が重要です。

Androidでの代表的な確認観点

Manifest等で要求する権限が必要最小限で、不要な権限が残っていないか確認します。
インテント等のアプリ間連携で、外部からの呼び出し可否・エクスポート設定が適切か確認します。
暗号鍵がAndroidキーストア等の保護機構で生成・保管され、アプリ内にハードコードされていないか確認します。
端末・ネットワークが不正状態でも検知できるよう、ログ取得と閾値設定による監視設計ができているか確認します。

診断手法と実施タイミング

ツール診断と手動診断の使い分け

ツール診断（自動スキャン）と手動診断（専門家の検証）は、目的が異なるため併用が基本です。が示すとおり、脆弱性の診断・評価を担う担当者は、ネットワーク、OS、ミドルウェア、アプリケーションまで見渡して検査し、結果を評価します。スマホアプリでは、ツールで拾える「既知の問題」と、人が見つける「設計・仕様由来の問題」が混在します。

区分	得意	限界
ツール診断	既知パターンの検出、設定の初期点検、ライブラリの脆弱性の洗い出し	業務仕様に依存するロジック欠陥（権限チェック漏れ等）を見抜きにくい
手動診断	画面操作と通信改ざん等で、認可不備・仕様の穴を深掘りできる	範囲が広いほど工数が増え、準備（環境・アカウント・資料）が品質を左右する

ツール診断と手動診断の向き不向き

実務上は、ツールで広く当たりを付け、重要機能（認証、決済、個人情報の参照・更新、管理者機能）を手動で重点的に検証する設計が、費用対効果と漏れの少なさのバランスが取りやすいです。

開発中から定期診断までの頻度

診断頻度は、変更量（リリース内容）とリスク（扱うデータ・外部公開範囲）に合わせて決めます。ペネトレーションテストは依頼から完了まで数カ月かかり得るため、直前に慌てて実施する類のものではないとされています。スマホアプリ診断でも、公開直前に詰め込むと、修正・再テストの余裕がなくなるため、開発計画に組み込む必要があります。

頻度設計で織り込む運用要件

OS・アプリを最新状態に保つ運用は継続必須で、診断結果の前提条件になります。
サーバ側ではログ取得と閾値設定（CPU・メモリ・ネットワークトラフィック等の異常値検知）を整備し、診断で見つかった高リスク事象の検知・追跡を可能にします。
大きな変更の前に診断期間を確保し、必要なら侵入テストは完了まで数カ月かかる前提で逆算します。

新機能追加時に再診断を省略しやすい変更と、必ず見直すべき変更

再診断の要否は「データの通り道」と「権限境界」に触れるかで判断するとブレにくいです。重要なシステム間の接続点を洗い出して概要を把握し、その後の詳細調査は優先順位を付けて計画的に取り組むことが望ましい、と整理されています。

変更の種類	省略しやすい（条件付き）	必ず見直す
UI・表示	文言修正、デザイン変更、静的コンテンツ追加	入力項目追加で個人情報の扱いが増える場合
通信・API	既存APIを触らず、通信経路・認証方式も不変	新API追加、既存APIの権限判定変更、通信暗号化方式変更
認証・権限	文言や画面遷移のみで認証ロジック不変	ログイン方式変更、トークン設計変更、管理者機能追加
運用・監視	軽微なログ文言修正	ログ取得・閾値設定・通知先の変更（検知不能化のリスク）

再診断の判断軸（省略しやすい／必ず見直す）

省略する場合でも、少なくとも「差分影響の説明（どこに触れていないか）」を残し、監査・説明責任に耐える意思決定記録にしておくと、法務・コンプライアンス側の判断がしやすくなります。

スマホアプリ診断の進め方

事前ヒアリングから報告書提出まで

診断プロジェクトは、事前ヒアリング→準備→診断→報告の順に進め、各工程で「ベンダーが必要とする情報が揃っているか」をゲートにします。第三者である外部専門組織により、再構築されたパソコン・サーバ・クラウド・ネットワーク等のセキュリティが確保されていることを確認する重要性が示されています。スマホアプリ診断でも、外部チェックを形骸化させないために、対象・方法・成果物を事前に合意します。

実務での進行ステップ

ヒアリングで機能一覧、認証方式、データ種別、外部連携、運用監視（ログ取得・閾値設定の有無）を整理します。
検証環境（ステージング等）、検証アカウント、診断用ビルド（配布物）を準備し、範囲外への影響を避ける前提を固めます。
診断で、端末側の保存・権限・改ざん耐性、通信（暗号化・証明書検証）、APIの認可・入力検証を一連のフローで確認します。
報告書で指摘事項を重要度別に整理し、修正方針（暫定対策／恒久対策）と再テスト範囲を合意します。

報告書の読み方と開発への返し方

報告書は「直すべき点の羅列」ではなく、リスク判断と是正管理のための材料です。にあるとおり、脆弱性の情報を収集して影響範囲を特定し、原因を取り除く方法を特定して対処方法を確定し、場合によっては緩和策（攻撃を実現させない措置）を提供する、という流れが重要です。報告書の読み方も同様に、原因と影響と対策（恒久／緩和）をセットで扱います。

報告書から開発タスクへ落とすときの観点

影響範囲（どのデータが、誰に、どの経路で漏れるか）を先に確定し、修正の優先度を揃えます。
恒久対策が間に合わない場合は、緩和策（機能停止、アクセス制限、監視強化）を先に入れて被害を防ぎます。
ログ取得と閾値設定が弱い場合、修正と並行して検知・追跡の運用改善もタスク化します。

情シス・開発・法務で診断前にそろえる資料は何か

診断品質は、事前に提供できる資料と権限付与（環境・アカウント）で大きく変わります。が示す「第三者チェック」を成立させるには、技術面だけでなく、情報提供と取り扱いに関する合意（NDA等）も含めて準備が必要です。

部門別に事前準備しておくと手戻りが減るもの

開発：画面遷移、API一覧、認証・認可フロー、外部連携（SDK/決済等）、ログ出力方針を用意します。
情シス：検証環境のネットワーク到達性、端末準備、監視（ログ取得と閾値設定、通知先）を整理します。
法務・コンプライアンス：個人情報保護法20条（個人情報保護法第20条）の安全管理措置との整合、委託先との機密保持、診断実施同意（業務影響の扱い）を整備します。

費用とベンダー選定

費用相場と見積りを左右する要素

費用は診断範囲と深さに比例しますが、が薄いため、本稿では金額の断定は避け、見積りの構造（何が工数を増やすか）に絞って整理します。にある「ネットワーク、OS、ミドルウェア、アプリケーションまで検査し、結果を評価する」という診断担当の役割に照らすと、対象が増えるほど評価・検証の工数が増えるのは自然です。

見積りに効きやすい要素（スマホアプリ領域）

OS別（iOS/Android）に実機検証が必要かどうかで工数が分かれます。
API本数、認証・権限パターン、外部連携点の多さが、手動検証の工数に直結します。
サーバ／クラウドの設定不備確認、ログ取得と閾値設定など運用面の確認を範囲に入れると、関係者調整と検証観点が増えます。

ベンダー比較で見る体制とソースコード対応

ベンダー選定では、誰が診断し、どう評価するかを確認します。の定義どおり、脆弱性診断士はネットワーク、OS、ミドルウェア、アプリケーションの検査と診断結果の評価を担うため、診断結果の「指摘」だけでなく「評価と優先度付け」「緩和策の提案」まで一貫してできる体制かが重要です。

比較時に確認したい実務ポイント

アプリ／API／サーバまで含めた範囲設計に対応できる体制かを確認します。
ブラックボックス（動的）だけでなく、必要に応じてソースコードを用いた確認（静的）に対応できるかを確認します。
報告書で、影響範囲の特定→原因→恒久対策／緩和策までの説明があるかを見本で確認します。

Web診断との違いと組み合わせ方

Web診断は主にサーバ側の攻撃面（入力検証不備、認可不備、設定不備等）を中心に扱いますが、スマホアプリ診断は端末側の保存・権限・改ざん耐性といった「配布物ならでは」の論点が加わります。外部公開サーバや通信機器への脆弱性診断、クラウド環境の設定不備確認などが第三者チェックとして重要とされており、アプリ診断とWeb／インフラ診断を組み合わせることで、データの通り道全体をカバーしやすくなります。

組み合わせの設計例（目的ベース）

個人情報を扱うAPIはWeb診断で認可・入力検証・設定不備を確認し、アプリ診断で端末内保存や通信実装を確認します。
サーバ側ではログ取得と閾値設定を整備し、診断で見つかった攻撃シナリオを「検知できるか」まで落とします。

見積りで追加費用になりやすい条件は何か

追加費用は、範囲のブレと準備不足で発生しやすいです。ペネトレーションテストは事前準備や調整が必要で、完了まで数カ月かかることもあります。スマホアプリ診断でも、短納期化や資料不足は同様にベンダー側の要員確保・調査工数を押し上げます。

追加費用の要因になりやすい事象

仕様や対象範囲の確定が遅れ、診断中に「追加で見るべきAPI・機能」が増えるケースがあります。
検証環境やアカウントが不安定で、診断が中断・再実施になり日程変更が発生するケースがあります。
暗号化や独自仕様の挙動が資料化されておらず、事前調査（解析）工数が増えるケースがあります。

よくある質問

外注開発のスマホアプリでも診断は必要ですか？

外注開発であっても、運営主体である自社が、第三者による診断を意思決定として組み込む必要があります。外部専門組織により再構築されたパソコン、サーバ、クラウド、ネットワーク等のセキュリティが確保されていることを確認する「セキュリティ第三者チェック」が重要だとされています。外注先の自己点検だけでは、チェックが独立しておらず、範囲や深さが発注側のリスク許容度と一致しないことがあります。

実務では、契約・検収の観点からも、診断結果（指摘と是正）を納品物の品質要件として位置付け、必要に応じて修正を外注先に反映させる運用にすると、再発防止まで含めて管理しやすくなります。

無料のツールだけで対策は十分ですか？

無料ツールは初期スクリーニングとして有用ですが、それだけで十分とは言い切れません。が示すとおり、脆弱性分析は、技術情報の収集→技術調査→影響範囲特定→対処方法の確定までを含み、場合によっては緩和策の提示も行います。ツールは「検出」には寄与しますが、影響範囲の特定や業務仕様に基づく評価、緩和策の設計は人手が必要になりがちです。

また、運用面ではサーバのログ取得と閾値設定が重要で、単に脆弱性を潰すだけでなく「怪しい動きがあったときに追えるか」まで含めた体制を作る必要があります。

iOSとAndroidをまとめて診断する注意点は？

iOSとAndroidは、権限設計、データ保存、鍵管理、例外設定の考え方が異なります。スマホOSは設計上のセキュリティレベルは高い一方で脆弱性は発見され続けるため、両OSで「最新状態を維持する」運用も含め、前提を分けて確認します。

一括発注でも分けて確認したい点

iOSは設定（ATS等）とキーチェーンのアクセス制御、端末状態（脱獄等）への対処方針を確認します。
Androidは権限（パーミッション）最小化、インテント等の公開範囲、キーストアを用いた鍵管理を確認します。
両OS共通で、サーバ側のログ取得と閾値設定により不正挙動を追跡できるかを確認します。

Highリスクの指摘が出たら何を優先しますか？

Highリスク（重大）の指摘が出た場合は、恒久修正の前に「被害を出さない／広げない」ための封じ込めと、被害範囲の特定を優先します。にも、初期手掛かり（被疑アカウント、IoC、TTPs等）を基に調査を繰り返し、被害範囲を特定していく考え方が示されています。

優先順位（実務対応）

影響するAPIや機能を一時停止・制限し、攻撃の通り道を塞ぐ緩和策を入れます。
サーバのログを確認し、の考え方に沿って手掛かりを増やしながら被害範囲を特定します。
再発防止として、ログ取得と閾値設定（異常値の自動通知）を整備し、検知・初動を早めます。
恒久対策（設計・実装の修正）を行い、必要範囲で再診断し、是正の完了を確認します。

スマホアプリ診断への対応で次にすべきこと

スマホアプリ診断は、アプリ単体ではなくアプリ・API・サーバを一体のデータフローとして捉え、認証・通信・データ保護の3本柱で確認することで、部門間の合意と是正管理に乗せやすくなります。再診断の要否は「データの通り道」と「権限境界」に触れるかで判断し、個人情報保護法20条（個人情報保護法第20条）の安全管理措置として説明できる線引きと記録を残すことが実務上のポイントです。侵入テストまで含める場合は完了まで数カ月かかり得るため、公開直前に詰め込まず、修正・再テストを見込んだ日程で逆算します。次のアクションとして、まず取り扱いデータと外部連携点を棚卸しし、診断範囲（アプリ／API／サーバ／クラウド設定・運用）と必要資料を確定したうえで、診断結果の評価・優先度付け・緩和策まで対応できる体制かをベンダーに確認してください。個別の判断は、開発・情シス・法務・コンプライアンスで前提を揃え、必要に応じて専門家に相談する前提で進めるのが安全です。