スマートフォンアプリは、金融サービス、EC、医療、物流、社内業務など、さまざまな分野で利用されています。企業にとってモバイルアプリは、顧客との重要な接点であると同時に、個人情報や業務データを取り扱うシステムでもあります。
一方、モバイルアプリには、Webアプリケーションとは異なるセキュリティリスクが存在します。端末内への機密情報の保存、通信内容の保護、OS固有の機能との連携、アプリの解析・改ざんなど、確認すべき範囲は多岐にわたります。
こうしたリスクを把握し、適切な対策につなげるために重要なのが、モバイルアプリ脆弱性診断です。
本記事では、モバイルアプリ脆弱性診断の基本から、主な診断項目、iOSとAndroidの違い、実施方法、費用、国際的なセキュリティ基準であるOWASP MASVS・MASTGまで解説します。
モバイルアプリ脆弱性診断とは?

モバイルアプリ 脆弱性診断とは、iOSやAndroid向けに開発されたアプリケーションに存在するセキュリティ上の弱点を調査し、リスクを評価する取り組みです。
アプリのソースコードや実行ファイル、端末内のデータ保存、ネットワーク通信、認証機能、外部APIとの連携などを対象に、安全性を確認します。
例えば、ログイン後に発行される認証トークンが端末内に不適切に保存されていた場合、端末への不正アクセスなどを通じて情報が取得される可能性があります。また、アプリとサーバー間の通信やアクセス制御に問題がある場合、ユーザー情報の漏えいや不正操作につながるおそれがあります。
モバイルアプリ 脆弱性診断の目的は、単に問題を検出することではありません。発見した脆弱性の影響を評価し、修正の優先順位を明確にすることで、アプリの安全性を高めることが重要です。
Webアプリケーション脆弱性診断との違い
Webアプリケーション脆弱性診断は、主にブラウザから利用するWebシステムの機能や通信、認証、アクセス制御などを評価します。
一方、モバイルアプリ 脆弱性診断では、これらに加えて、スマートフォン端末やOSに固有のセキュリティ要素も確認する必要があります。
| 比較項目 | Webアプリケーション脆弱性診断 | モバイルアプリ 脆弱性診断 |
|---|---|---|
| 主な対象 | Webサイト、業務Webシステム | iOS・Androidアプリ |
| 実行環境 | Webブラウザ | スマートフォン、タブレット |
| データ保存 | Cookie、ブラウザストレージなど | 端末内ストレージ、Keychain、Keystore関連の実装など |
| 主な確認事項 | 入力処理、認証、アクセス制御、セッション管理 | 端末内保存、通信、認証、OS連携、アプリ解析・改ざん耐性 |
| 共通する確認事項 | API、認証、アクセス制御など | API、認証、アクセス制御など |
なお、モバイルアプリもサーバー側のAPIを利用するケースが多いため、アプリ単体の診断だけでは十分とは限りません。必要に応じて、バックエンドAPIや関連システムも含めて評価することが重要です。
Webシステムの診断については、関連記事「Webアプリケーション脆弱性診断とは?診断項目・費用・実施手順を解説」をご覧ください。
モバイルアプリに潜む主なセキュリティリスク
モバイルアプリは、利用者の端末上で動作するという特性上、サーバー側だけでなく、端末内の処理やデータの取り扱いにも注意が必要です。
代表的なセキュリティリスクを確認しましょう。
1. 端末内に保存された機密情報の漏えい
モバイルアプリでは、ログイン情報、認証トークン、個人情報、業務データなどを端末内に保存する場合があります。
これらの情報が適切に保護されていない場合、端末の紛失・盗難、不正なバックアップの取得、端末の侵害などを通じて情報が漏えいする可能性があります。
特に、認証トークンやパスワードなどの重要情報については、保存の必要性を検討したうえで、OSが提供する安全な仕組みを適切に利用することが重要です。
2. 通信の保護が不十分
モバイルアプリは、ログイン処理やデータ取得、決済、通知などのために、外部サーバーと頻繁に通信します。
通信経路の暗号化やサーバー証明書の検証が不適切な場合、通信内容の盗聴や改ざん、中間者攻撃などのリスクが高まります。
HTTPSを使用しているだけでなく、TLSの設定や証明書検証が適切に実装されているか確認する必要があります。
3. 認証・アクセス制御の不備
認証機能に問題があると、第三者による不正ログインやアカウントの乗っ取りにつながる可能性があります。
また、ログイン自体が適切でも、サーバー側のアクセス制御が不十分であれば、他のユーザーの情報を取得・変更できてしまう場合があります。
モバイルアプリでは、端末側の画面表示や操作制限だけに依存せず、サーバー側でも利用者の権限を検証することが重要です。
4. アプリのリバースエンジニアリング・改ざん
モバイルアプリの実行ファイルは利用者の端末に配布されるため、第三者がその構造や処理を解析する可能性があります。
例えば、アプリ内にAPIキーや秘密情報を直接埋め込んでいる場合、解析によって情報が露出するおそれがあります。
また、アプリの処理を改変して、本来想定していない操作を試みるケースも考えられます。
コード難読化や改ざん検知などはリスク低減に役立つ場合がありますが、完全な防御を保証するものではありません。重要な認可処理や秘密情報の保護は、サーバー側の設計も含めて検討する必要があります。
5. 外部ライブラリ・SDKに起因するリスク
多くのモバイルアプリでは、分析ツール、広告SDK、決済SDK、認証ライブラリなどの外部コンポーネントが利用されています。
これらのコンポーネントに既知の脆弱性が存在したり、不要な情報を収集・送信したりする場合、アプリ全体のセキュリティやプライバシーに影響を与える可能性があります。
そのため、アプリ本体の実装だけでなく、利用しているライブラリやSDKの管理状況も確認することが重要です。
モバイルアプリ脆弱性診断の主な診断項目

モバイルアプリ 脆弱性診断では、アプリの構成や取り扱う情報、利用環境に応じて診断項目を設定します。
代表的な診断項目は次のとおりです。
| 診断項目 | 主な確認内容 | 想定されるリスク |
|---|---|---|
| データ保存 | 機密情報の保存先、保存形式、不要データの残存 | 情報漏えい |
| 暗号化 | 暗号アルゴリズム、鍵の管理、乱数の利用 | データの解読・改ざん |
| 認証・認可 | ログイン、トークン管理、権限確認 | 不正ログイン・権限外アクセス |
| ネットワーク通信 | TLS、証明書検証、通信設定 | 通信の盗聴・改ざん |
| OS・プラットフォーム連携 | 権限、外部アプリ連携、コンポーネント公開設定 | 不正な機能呼び出し |
| コード品質 | セキュリティ設定、依存ライブラリ、秘密情報の埋め込み | 脆弱性の悪用 |
| 解析・改ざん耐性 | リバースエンジニアリングや改ざんへの対策 | アプリの不正改変 |
| プライバシー | 個人情報の収集、利用、送信、同意管理 | 不適切な情報取り扱い |
静的解析と動的解析
モバイルアプリ 脆弱性診断では、静的解析と動的解析を組み合わせることがあります。
静的解析(Static Analysis)は、ソースコードやアプリの実行ファイルなどを調査し、セキュリティ上の問題を確認する方法です。機密情報の埋め込み、不適切なAPIの使用、危険な設定などの発見に役立ちます。
一方、動的解析(Dynamic Analysis)は、アプリを実際に動作させながら、通信や認証処理、データの保存状況などを確認する方法です。
静的解析では実際の動作条件による問題を把握しきれない場合があり、動的解析だけでは内部実装の問題を十分に確認できない場合があります。
そのため、診断目的に応じて両方を活用し、必要に応じて専門家による手動検証を実施することが重要です。
iOSとAndroidの脆弱性診断の違い
iOSとAndroidでは、アプリの実行環境や権限管理、データ保存、外部アプリとの連携方法などが異なります。
そのため、同じ機能を提供するアプリであっても、OSごとの特性を考慮して診断する必要があります。
iOSアプリの主な診断ポイント
iOSアプリでは、Appleが提供するセキュリティ機構を適切に利用しているか確認します。
代表的な確認項目は、以下のとおりです。
-
Keychainなどを利用した機密情報の保存
-
App Transport Security(ATS)やTLS通信の設定
-
アプリ間のデータ共有やURL Schemeなどの取り扱い
-
アプリの権限設定と個人情報へのアクセス
-
認証情報やセッションの管理
-
アプリ内に埋め込まれた秘密情報の有無
例えば、Keychainを利用していても、保存する情報やアクセス条件が適切でなければ、必要な保護を実現できない可能性があります。
Androidアプリの主な診断ポイント
Androidアプリでは、アプリコンポーネントの公開設定や権限管理、端末内ストレージの利用などが重要な確認対象となります。
代表的な確認項目は、以下のとおりです。
-
AndroidManifest.xmlの設定
-
Activity、Service、Broadcast Receiver、Content Providerの公開範囲
-
アプリ間通信を行うIntentの取り扱い
-
端末内ストレージと機密情報の保存方法
-
Android Keystoreを利用した鍵管理
-
WebViewの設定やJavaScriptインターフェース
-
ネットワークセキュリティ設定
例えば、外部公開が不要なコンポーネントがアクセス可能な状態になっている場合、他のアプリから意図しない操作を実行される可能性があります。
iOSとAndroidの比較
| 比較項目 | iOS | Android |
|---|---|---|
| 主な開発言語 | Swift、Objective-Cなど | Kotlin、Javaなど |
| 機密情報の保護 | Keychainなど | Android Keystoreなど |
| 通信設定 | ATS、TLS設定など | Network Security Configuration、TLS設定など |
| OS連携 | URL Scheme、Universal Linksなど | Intent、App Links、各種コンポーネント |
| 特に確認したい点 | Keychain設定、データ共有、権限 | コンポーネント公開、Intent、WebView、権限 |
なお、FlutterやReact Nativeなどのクロスプラットフォーム技術を利用している場合でも、OS固有の設定やネイティブ機能が存在するため、iOSとAndroidの両方を確認する必要があります。
モバイルアプリ脆弱性診断の実施方法と流れ

モバイルアプリ 脆弱性診断は、一般的に対象範囲の確認から診断結果の報告、修正後の再確認まで、複数のステップで進められます。
ステップ1:診断対象と目的の確認
最初に、診断するアプリと対象範囲を明確にします。
iOSとAndroidのどちらを対象とするか、ログイン機能や決済機能、外部APIなどをどこまで含めるかを整理します。
また、個人情報や決済情報など、取り扱うデータの重要性に応じて、重点的に確認する項目を設定します。
ステップ2:診断環境と必要情報の準備
診断を開始する前に、必要な環境や情報を準備します。
例えば、アプリの検証用ビルド、テストアカウント、API仕様、検証環境への接続情報などです。
本番環境への影響を避けるため、可能な限り専用の検証環境を利用することが望まれます。
ステップ3:静的解析・動的解析の実施
アプリの構成や実装を調査し、セキュリティ上の問題を確認します。
静的解析では、アプリ内部の設定やコード、利用ライブラリなどを調べます。
動的解析では、実際のアプリ操作を通じて、通信内容や認証処理、データ保存などを確認します。
ステップ4:脆弱性の検証とリスク評価
検出された問題について、実際の影響や悪用可能性を確認します。
ツールが検出した結果には誤検知が含まれる場合があるため、必要に応じて手動で検証します。
そのうえで、脆弱性の深刻度、影響を受ける情報や機能、悪用の条件などを整理し、修正の優先順位を検討します。
ステップ5:診断結果の報告と改善提案
診断後は、検出した問題と推奨される対策を報告書にまとめます。
報告書には、脆弱性の概要、影響範囲、発生条件、リスク評価、修正方針などを含めることが一般的です。
開発担当者が具体的な修正作業に取り組めるよう、技術的な情報を整理することが重要です。
ステップ6:修正と再診断
診断で発見された脆弱性を修正した後、必要に応じて再診断を実施します。
修正が適切に反映されているかを確認するとともに、変更によって新たな問題が発生していないかも確認します。
モバイルアプリは継続的に更新されるため、一度の診断で終わらせず、重要な機能変更やリリースのタイミングに合わせてセキュリティを評価することが望まれます。
モバイルアプリ 脆弱性診断の費用と期間

モバイルアプリ 脆弱性診断の費用は、診断対象や機能の複雑さ、診断方法などによって異なります。
例えば、単純な情報表示アプリと、ログイン・決済・個人情報管理・外部API連携を備えたアプリでは、確認すべき項目や作業量が大きく異なります。
そのため、すべてのモバイルアプリに共通する料金を設定することは難しく、実際の費用は対象範囲に応じた見積もりで確認する必要があります。
費用を左右する主な要因
| 要因 | 費用に影響する理由 |
|---|---|
| 対応OS | iOSとAndroidの両方を診断する場合、OS固有の検証が必要になる |
| アプリの機能数 | ログイン、決済、データ管理などの機能が増えると確認範囲が広がる |
| APIの数・複雑さ | 外部サービスやバックエンドとの連携が多いほど検証対象が増える |
| 診断方法 | 自動診断に加え、手動解析や詳細な検証を行う場合は工数が増える |
| ソースコードの提供有無 | ソースコードを利用できるかによって解析方法が変わる |
| 再診断の有無 | 修正後の確認を契約に含めるかによって総費用が変わる |
診断期間の目安
診断期間についても、アプリの規模や対象範囲によって異なります。
小規模なアプリであれば比較的短期間で実施できる場合がありますが、複数のOS、複雑な認証機能、多数のAPI連携などを含む場合は、より長い期間が必要になることがあります。
また、診断作業そのものに加えて、事前準備、結果の確認、報告書作成、修正後の再診断にかかる時間も考慮する必要があります。
見積もりを依頼する際には、料金だけでなく、診断範囲、実施期間、報告書の内容、再診断の条件まで確認しましょう。
脆弱性診断全般の費用については、関連記事「脆弱性診断の費用はいくら?料金の決まり方・見積もりのポイントを解説」でも詳しく紹介しています。
OWASP MASVS・MASTGに基づくセキュリティ評価
モバイルアプリ 脆弱性診断では、国際的に利用されているセキュリティ基準やテストガイドを参考にすることが重要です。
代表的なものとして、OWASPが公開する「MASVS」と「MASTG」があります。
OWASP MASVSとは?
OWASP MASVS(Mobile Application Security Verification Standard)は、モバイルアプリのセキュリティ要件を体系的に整理した検証基準です。
アプリ開発者がセキュリティ要件を定義する際や、診断担当者が評価範囲を検討する際に活用できます。
MASVSでは、主に次の領域が整理されています。
| 分類 | 評価領域 |
|---|---|
| MASVS-STORAGE | データ保存 |
| MASVS-CRYPTO | 暗号化 |
| MASVS-AUTH | 認証・認可 |
| MASVS-NETWORK | ネットワーク通信 |
| MASVS-PLATFORM | OS・プラットフォームとの連携 |
| MASVS-CODE | コード品質 |
| MASVS-RESILIENCE | リバースエンジニアリング・改ざんへの耐性 |
| MASVS-PRIVACY | プライバシー保護 |
出典:OWASP Mobile Application Security Verification Standard
OWASP MASTGとは?
OWASP MASTG(Mobile Application Security Testing Guide)は、モバイルアプリのセキュリティテストに関する技術的なガイドです。
MASVSが「どのようなセキュリティ要件を満たすべきか」を整理するのに対し、MASTGは「どのように検証するか」を具体的に示します。
MASTGには、AndroidとiOSのセキュリティテストに関する説明や、検証技術、テストケースなどが掲載されています。
そのため、MASVSとMASTGを組み合わせることで、診断項目の整理と具体的な検証方法の検討に役立ちます。
出典:OWASP Mobile Application Security Testing Guide
日本企業が参考にしたいセキュリティガイドライン
日本国内では、一般社団法人日本スマートフォンセキュリティ協会(JSSEC)も、スマートフォンアプリの安全な開発に関するガイドを公開しています。
「スマートフォンアプリケーション開発者の実施規範」では、セキュアコーディングやセキュリティテストの重要性が示され、OWASP MASVSやMASTGなども参考資料として紹介されています。
モバイルアプリの開発・運用を行う企業は、こうしたガイドラインも活用しながら、必要なセキュリティ要件を整理するとよいでしょう。
出典:JSSEC「スマートフォンアプリケーション開発者の実施規範」
モバイルアプリ 脆弱性診断サービスの選び方
モバイルアプリ 脆弱性診断を外部に依頼する際には、料金だけでなく、診断範囲や技術的な対応力、報告内容などを確認することが重要です。
- iOS・Androidの両方に対応しているか:iOSとAndroidでは、セキュリティ機構やアプリの実装方法が異なります。両方のOSでアプリを提供している場合は、それぞれの環境に対応した診断が可能か確認しましょう。また、FlutterやReact Nativeなどを利用している場合は、クロスプラットフォームアプリへの対応範囲も確認するとよいでしょう。
- 診断対象と項目が明確か:「モバイルアプリ 脆弱性診断」という名称が同じでも、サービスによって対象範囲は異なります。アプリ本体だけを診断するのか、バックエンドAPIや認証基盤まで含むのかを確認する必要があります。特に、個人情報や決済情報を取り扱うアプリでは、重要な機能が診断範囲から漏れていないか注意しましょう。
- 自動診断と手動診断を適切に組み合わせているか:自動診断は、既知の問題や設定上の不備などを効率的に確認する際に役立ちます。一方、複雑な認証処理や業務ロジックに関する問題は、ツールだけでは十分に検出できない場合があります。そのため、アプリの特性に応じて、専門家による手動検証がどこまで含まれるか確認することが重要です。
- OWASPなどの基準を参考にしているか:OWASP MASVSやMASTGなどの基準を活用しているかも、比較する際のポイントです。ただし、基準名を掲げているだけで診断の品質が保証されるわけではありません。実際にどの項目を確認し、どのような方法で評価するのかを確認することが大切です。
- 診断後の改善につながる報告があるか:診断結果は、開発担当者が修正に活用できる内容であることが重要です。脆弱性の概要だけでなく、影響範囲、再現条件、リスクの深刻度、推奨される対策などが整理されているか確認しましょう。また、修正後の再診断や技術的な相談への対応範囲も、事前に確認しておくと安心です。
SotaTek Japanの脆弱性診断サービス
SotaTek Japanは、Webアプリケーション、iOS・Android向けモバイルアプリ、サーバー・ネットワーク環境を対象に、企業のセキュリティリスクを可視化する脆弱性診断サービスを提供しています。
専門エンジニアが診断ツールや対象システムに応じた検証手法を活用し、機密情報の保存、認証・アクセス制御、ネットワーク通信など、さまざまな観点から潜在的な脆弱性を調査・評価します。
SotaTek Japanが重視するのは、診断結果を実際のセキュリティ改善に結びつけることです。
検出された脆弱性について、リスクの深刻度や想定される影響を整理し、具体的な改善策を提示します。さらに、診断後の質疑応答や、必要に応じた再診断にも対応し、企業の継続的なセキュリティ対策を支援します。
モバイルアプリの新規リリース、機能追加、既存アプリのセキュリティ見直しなどをご検討の際は、ぜひSotaTek Japanへご相談ください。
よくある質問(FAQ)

モバイルアプリ 脆弱性診断は必ず実施する必要がありますか?
すべてのモバイルアプリに対して、法律で一律に脆弱性診断が義務付けられているわけではありません。ただし、取り扱う情報や業界、契約条件などによって、セキュリティ対策や評価が求められる場合があります。
特に、個人情報や決済情報、機密性の高い業務データを取り扱うアプリでは、リリース前や重要な機能変更時に脆弱性診断を実施することが推奨されます。
モバイルアプリ 脆弱性診断はどのくらいの頻度で実施すべきですか?
診断頻度は、アプリの重要性や更新頻度、取り扱うデータの種類によって異なります。
一般的には、新規リリース前、大規模なアップデート時、認証・決済機能の変更時などが重要な実施タイミングです。また、利用するライブラリやOSの更新、重大な脆弱性の公表などをきっかけに、追加の診断を検討することも重要です。
アプリのソースコードがなくても脆弱性診断はできますか?
はい、ソースコードが提供されない場合でも、アプリの実行ファイルを使用したブラックボックス診断などを実施できる場合があります。
ただし、ソースコードを利用できる場合と比べて、内部処理や実装上の問題を確認できる範囲が制限されることがあります。診断の目的や対象範囲に応じて、適切な方法を選択する必要があります。
iOSとAndroidの両方を診断する必要がありますか?
iOSとAndroidの両方でアプリを提供している場合は、それぞれの環境で診断することが望まれます。
両OSでは、データ保存、権限管理、アプリ間通信などの仕組みが異なるため、一方の診断結果だけですべてのリスクを把握できるとは限りません。
FlutterやReact Nativeなどで開発されたアプリについても、OS固有の設定や機能を確認する必要があります。
App StoreやGoogle Playの審査に通過していれば安全ですか?
App StoreやGoogle Playの審査に通過したことは、アプリに脆弱性が存在しないことを保証するものではありません。
アプリストアの審査と専門的な脆弱性診断では、確認する目的や範囲が異なります。
そのため、審査に通過したアプリであっても、認証・アクセス制御、機密情報の保存、ネットワーク通信などについて、必要に応じたセキュリティ評価を実施することが重要です。
モバイルアプリの診断だけでAPIのセキュリティも確認できますか?
モバイルアプリ 脆弱性診断では、アプリとサーバー間の通信やAPIの利用方法を確認することがあります。
ただし、バックエンドAPI全体の認証・認可、アクセス制御、入力値処理などが、必ずしもすべて診断対象に含まれるとは限りません。
APIを含むシステム全体の安全性を評価したい場合は、診断を依頼する際に対象範囲を明確にすることが重要です。
脆弱性が発見された場合、どのように対応すればよいですか?
まず、検出された脆弱性の深刻度や影響範囲、悪用される可能性を確認し、修正の優先順位を決定します。
そのうえで、開発担当者が必要な修正を行い、修正後に再診断を実施して問題が解消されているか確認します。
特に重大な脆弱性については、修正が完了するまでの暫定的な対策も検討する必要があります。
SotaTek Japanでは、脆弱性の調査・評価に加え、診断結果に基づく改善策の検討を支援しています。
まとめ
モバイルアプリ 脆弱性診断は、iOSやAndroidアプリに存在するセキュリティ上の弱点を発見し、情報漏えいや不正アクセスなどのリスクを低減するための重要な取り組みです。
モバイルアプリでは、端末内のデータ保存、ネットワーク通信、認証・アクセス制御、OSとの連携、アプリの解析・改ざん耐性など、幅広い項目を確認する必要があります。
また、OWASP MASVS・MASTGなどの基準を参考にしながら、アプリの機能や取り扱う情報に応じた診断範囲を設定することが重要です。
診断サービスを選ぶ際には、費用だけでなく、対象OS、診断項目、手動検証の範囲、報告書の内容、修正後の対応まで確認しましょう。
モバイルアプリの安全性を継続的に高めるためには、開発段階からセキュリティを考慮し、リリース前や重要な機能変更時に適切な診断を実施することが大切です。