スマホアプリの中身は誰でも見られる：「鍵」の管理を見直した事例

ストアで配っているアプリは、ダウンロードした人なら誰でも中身を見られます。アプリの中に「鍵」（外部のサービスを使うための鍵。API キーとも呼びます）を入れておくと、いずれ他人に使われます。

アプリをつくれる人が増え、危ない置き方も増えている

ここ数年、Flutter や React Native のような、1 つの言語から iPhone と Android の両方のアプリをつくれる仕組み（クロスプラットフォーム）が広まりました。Web の開発をしてきたエンジニアなど、スマホアプリをつくった経験がない人でも、アプリをつくれるようになっています。

これは良いことですが、危ない面もあります。スマホアプリならではの「配ったものは中身を見られる」という前提を知らないと、Web の感覚で、鍵をアプリの中にそのまま入れてしまいがちです。

さらに最近は、AI の進化もあって、アプリの中身を取り出して調べる道具が、海外のオープンソースで出回っているのを頻繁に見かけるようになりました。中身を調べるハードルは、どんどん下がっています。

アプリは簡単に解析される時代になった

アプリを配ることは、荷物を不特定多数に送ることに似ています。受け取った人は、箱を開けて中身を一つずつ見られます。以前は箱を開けるのに専門の知識と手間が要りましたが、今は道具がそろい、誰でも簡単に開けられるようになりました。しかも荷物と違い、一度配ったアプリは回収できません。

実際に、解析が攻撃に使われています。情報通信研究機構（NICT）のサイトに掲載された注意喚起は、公開されているアプリを解析し、その結果からサーバを攻撃する手口を報告しています。「公開アプリが解析されること自体を完全に防ぐことは困難です」とも書いています。

アプリのセキュリティの基準をまとめている OWASP も、配布ファイルに入れたデータはダウンロードした誰もが取り出せると説明しています。被害の例として、取り出された鍵で課金されるサービスを勝手に使われ、予想外の請求が来ることを挙げています。

鍵の置き場所を見直しても、アプリの中には残る

私たちが関わった iOS アプリでは、Info.plist（アプリの名前や使う機能などを書いておく、iPhone アプリに必ず入っている設定ファイル）で利用する鍵は権限を絞ったファイル置き場（Amazon S3）に置き、アプリを自動で組み立てる仕組み（CI/CD）だけが取りに行きます。

もし、すでに鍵がアプリに入っている場合はどうなるでしょうか。
検証として小さな iPhone アプリを実際に組み立てて確かめました。鍵はすべて本物ではないダミーの文字列で、置き方を 3 通り試しています。

配布ファイルの中は、Mac に最初から入っている道具だけで見られました。そのときの画面の出力です。ダミーの鍵が、どれも読めています。

== Info.plist ==
  "LegacySdkKey" => "DUMMY-LEGACY-IN-PLIST"
  "SdkKey" => "DUMMY-FROM-XCCONFIG"
== 実行ファイル内の文字列 ==
DUMMY-SWIFT-LITERAL
DUMMY-SWIFT-LITERAL

鍵を知る人が減り、鍵の取り替えも楽になるので、管理を見直す意味はあります。ただし、配布するアプリの中身は、見直しの前と同じように読めます。また、古い鍵が残っている場合は、新しい鍵に取り替える必要があります。

本当の対策は「アプリに鍵を入れない」こと

まず「公開前提の鍵」かどうかを確かめる

鍵には、アプリに入れて配ることを前提につくられたもの（公開前提の鍵）があります。たとえば Firebase（Google Cloud Platformのサービス） の API キーは、Firebase の公式の説明で「公開を前提にした設計」とされ、使える範囲を Firebase に絞っていれば、アプリに入れても安全だとされています。Stripe（決済サービス）の「公開可能キー」も、アプリに入れてよいと説明されています。このキーでは、お金の請求のような大事な操作はできません。

ただし、公開前提の鍵でも、使える範囲や回数を絞る設定はしておきます。Firebase も、すべての鍵に制限をかけることが大事だとしています3。

一方、公開前提でない鍵は、必ずアプリに入れないようにします。Stripe も、外に出してよいのは公開可能キーだけで、ほかの鍵は自分で守る必要があるとしています。同じサービスの鍵でも、種類によって扱いが違う点に注意が必要です。たとえば Firebase でも、Gemini AIを呼ぶための鍵は、アプリに入れてはいけないとされています。

その鍵が公開前提かどうかは、サービスの公式の説明で確かめます。「公開前提」と書かれていない鍵は、入れてはいけない鍵として扱うのが安全です。

公開前提でない鍵はサーバに置く

読まれて困る鍵は、そもそもアプリに入れないのが根本の対策です。OWASP は、大事な鍵は会社のサーバ側に置き、アプリはサーバを経由してサービスを使う形を挙げています。アプリは会社のサーバにだけ話しかけ、サーバが利用者を確かめてから、大事な鍵で外部のサービスを呼びます。鍵は会社の外に出ません。

これまでiOS・Android のネイティブアプリと、クロスプラットフォームのアプリの両方の開発に取り組んできました。この記事の事例のように、鍵をアプリの中に入れない設計や、すでに入っている鍵の見直しも行っています。

「いまのアプリに鍵が入っていないか心配」「クロスプラットフォームでつくったアプリの守りを見直したい」といったご相談があれば、お気軽にお問い合わせください。

参考URL

1. NICT CYNEX 脅威情報分析チーム LETTICE「【注意喚起】相次ぐ情報漏洩、その原因の一つは『アプリ解析からのサーバ攻撃』」Rev 1.1（2026-10-13）https://cynex.nict.go.jp/pdf/library/lettice/261013-01.pdf↩︎

2. OWASP Mobile Application Security「MASWE-0004: Sensitive Data Hardcoded in the App Package」（2026-10-23 取得）https://mas.owasp.org/MASWE/MASVS-STORAGE/MASWE-0004/↩︎↩︎↩︎