スマホアプリの情報漏洩、原因は使い方だけじゃない｜アプリ自体の5つの経路と対策

他社のアプリから個人情報が漏れたというニュースを見て、自社のアプリは大丈夫だろうかと気になった担当者の方も多いのではないでしょうか。

ところが調べてみると、出てくるのは「スマホをなくさないように」「怪しいメールに注意」といった利用者の使い方の話ばかり。

知りたいのはそうした使い方の注意ではなく、自社アプリのプログラムや設定にどんな危険が潜んでいるかのはずです。

スマホアプリからの情報漏洩はどこから起きる？

情報漏洩の原因は、大きく「スマホの使い方」と「アプリ自体の作り」の2つに分かれます。

自社でアプリを提供する企業として対策すべきなのは、後者の「アプリ自体」に潜むリスクです。

スマホの紛失や偽メールのURLクリックなど、持ち主の「使い方」による情報漏洩

これらはいずれもスマホの持ち主の行動によるものなので、利用者に気をつけてもらうことで防ぐトラブルです。

データの保存や送信など、「アプリ自体」の作りによる情報漏洩

スマホアプリは端末に直接インストールされるため、データの保存方法や通信先はプログラムの設計によって決まります。もし重要情報を無防備に残したり外部へ送ったりしていれば、利用者がどれだけ気をつけて使っていても防ぎきれず、アプリ自体の作りが情報漏洩の原因になってしまいます。

実際に、2025年1月27日にはハンズのスマホアプリが不正アクセスを受け、12万1886件の個人情報が漏洩したと発表されました。

被害を受けるのは利用者ですが、対応やお詫び、信用の失墜を背負うのはアプリを提供している企業です。なお、会員データなどを預かるサーバー側とは別に、この記事では見落とされやすい「端末側のプログラムから漏れる経路」を中心に見ていきます。

アプリ自体から情報が漏れる主な5つの経路と対策

アプリ自体から情報が漏れる経路として、特に注意したいのは次の5つです。

①アプリに埋め込んだ重要情報：端末側に持たせない

プログラム内にAPIキー（外部サービスと連携するための認証情報）やパスワードといった重要情報が書き込まれていると、ファイルを解析された際にそのまま読み取られてしまいます。

「プログラムの中なら外から見えない」と思われがちですが、配布されているパッケージファイルは第三者でも解析できます。特にAndroidは、逆コンパイル（プログラムを読める形に戻すこと）によってソースコードまで読み取れてしまいます。

重要な情報をアプリ内に持たせず、サーバー側で管理する設計にしておけば、アプリを解析されて抜き取られるリスクを抑えられます。

②端末に保存した情報：本当に残す必要があるかを見直す

端末のストレージ（保存領域）にパスワードや個人情報を保存していると、端末の紛失や盗難の際に情報が読み取られるリスクがあります。

まずは「その情報を本当に端末側に残す必要があるのか」を設計段階で見直すことが大切です。

③ログやデバッグ機能：本番のアプリでは止める

開発時の確認用ログにパスワードや個人情報が含まれたまま、本番のプログラムに残っていることがあります。画面上は正常に動いていても、裏側の出力ログやデバッグ機能から情報が漏れてしまうおそれがあります。

本番向けのビルド（実際に配信するパッケージ）では、開発チームに依頼して重要情報のログ出力やデバッグ機能を確実に止めておくことが大切です。

④他のアプリに渡る情報（Android）：他のアプリからのアクセスを制限する

Androidには、他のアプリと連携するための機能（画面を開くActivityや裏で動くServiceなど）があります。

これらが外部からのアクセスを許可した設定（公開状態）になっていると、同じスマホに入っている別のアプリから画面を勝手に開かれたり、データを受け取られたりするおそれがあります。

また、システムの一斉通知（ブロードキャスト）に重要情報を流すのも危険です。他のアプリからアクセスできる機能を最小限に絞り、重要情報を一斉通知に流さない設定にしておく必要があります。

なお、Webリンクなどからアプリを開く仕組み（カスタムURLスキーム）はiOSにも共通するため、OSを問わず確認しておきたいポイントです。

⑤通信中に抜かれる情報：証明書の検証を省かない

サーバーとの通信時に相手が本物かを確かめる「SSL証明書の検証」を省いてしまうと、通信が暗号化されていても、偽のサーバーに接続された際にやり取りが盗み見られる危険が生じます。

テストの都合などで検証を一時的に無効化し、そのまま本番に公開してしまうケースが典型的です。

本番環境では証明書の検証を必ず有効にし、iOSではATS（App Transport Security、通信に安全な方式を使わせる仕組み）を無効にしていないかもあわせて確認します。

開発チームにこの3つを聞けば、自社アプリの現状が見えてくる

コードが読めない担当者や、開発を外部に委託している場合でも、自分でプログラムを調べる必要はありません。

開発チームに次の3つを確認すれば、自社の現状はおおよそ見えてきます。

パスワードなどの重要な情報を、アプリの中や端末に保存していませんか？

APIキーやパスワードなどの重要情報を、端末の保存領域やソースコード内、ログに残していないかを確認します。

「保存していない」という回答なら、「サーバー側で一括管理している」といった具体的な保管場所まで確認できるとひとまず安心材料になります。

逆に「保存している」場合は、本当に端末へ残す必要があるのかを一緒に見直す段階です。

サーバーとの通信で、SSL証明書の検証を省いていませんか？

通信相手を確かめる検証の有無や、iOSにおけるATSの無効化設定を確認します。

開発中にテストの都合で一時的に切ること自体は珍しくありません。大切なのは「本番のアプリでしっかり有効に戻っているか」という点です。

「本番では有効にしている」と明確に回答が得られるか確かめましょう。

最近追加した機能で、扱う個人情報や通信先が増えていませんか？

「前にも確認したから大丈夫」と思いがちですが、機能を追加・変更した部分には新しいリスクが入り込むことがあります。

アップデートのたびに、上の2つの質問（保存先と通信）を改めて確認する習慣をつけておくとリスクを抑えやすくなります。

もし答えが曖昧な部分があれば、そこが重点的に見直すべきポイントです。なお、他アプリとの連携設定やデバッグ機能の残存などは質問だけでは確かめきれないため、第三者の診断で見極めることになります。

見つかった問題に対処する2つのステップ

開発チームへの確認で見つかった懸念や、質問だけでは確かめきれない問題には、次の3ステップで対処します。

保存先やログ出力は、開発チームに直してもらう

端末への不要な保存やログ出力、デバッグ機能の停止などは、開発チーム側でコードや設定を見直すことで着手しやすい部分です。

開発を外部に委託している場合も、ヒアリングで見つかった問題点をそのまま開発会社に伝えて修正を依頼します。

実機での動きやアプリの中は、第三者の診断で確かめる

開発者はどうしても「想定通りの正常な使い方」を基準にテストしがちです。

実機での特異な挙動や、配布パッケージのファイルを解析する作業は、開発チームの目だけでは見落としが出やすいため、専門の脆弱性診断で第三者の客観的な目を入れるのが有効です。

これまで一度も診断を受けたことがない場合や、大型アップデートの直後、取引先からセキュリティ証明を求められたタイミングなどが、診断を検討すべき目安です。

私たちIFTでは、ツールによる自動診断と診断員による手動診断を組み合わせて対応しています。Androidアプリは逆コンパイル解析でソースコードレベルまで調査し、iOSアプリも、端末に残る情報や通信の安全設定まで入念に確認します。

なお、サーバー側の点検はWebアプリケーション診断の領域です。ログインや会員機能があるサービスなら、こちらもあわせて診断の対象に含まれます。

あわせて読みたい

Webアプリケーション診断とは？その効果と必要・不要の見極め方を専門家が解説

自社のWebサイトやサービスのセキュリティ、「本当に大丈夫？」と不安を感じていませんか？ 「『Webアプリケーション診断』を耳にするけれど、具体的に何をするの？」 「費用はどれくらい？」 「そもそも、うちの会社にも必要なの？」 このような疑問や不安、もしかしたらあなたも感じていませんか？

 

まとめ：まずは開発チームに、アプリの現状を聞いてみよう

私たちIFTでは、「診断して終わりじゃない、”改善”まで見届ける手厚いサポート」を大切にしています。漏れる経路を見つけて終わりではなく、直ったことを確かめるところまでが対策だと考えているからです。

自社アプリのどこを確認すればいいか迷っている方や、開発チームと話してみたものの不安が残る方は、お気軽にご相談ください。相談は無料です。