Tesujiアプリが動くために必要な情報と、利用者に渡してよい情報は同じではありません。ブラウザー向けコードや配布するアプリに秘密鍵を入れてしまうと、その鍵を前提としたサーバー側の保護も見直す必要があります。
なぜ今、確認したいのか
JPCERT/CCは2026年10月15日、攻撃元サーバーの調査から、Androidアプリの配布ファイルを解析してAPIを調べる攻撃の痕跡を報告しました。これは観測された攻撃の調査報告であり、国内のすべての漏えい事案の原因を一つに断定したものではありません。
同報告は、API認証に使う秘密鍵や長期間有効な認証情報をアプリへ埋め込まず、サーバー側で利用者の認証と操作の認可を行うことを推奨しています。JPCERT/CC Eyesの調査
「APIキー」という名前だけで判断しない
キーの公開可否は、発行元の仕様と与えられた権限で確認します。Stripeの場合は、フロントエンドに含められる公開可能キーと、公開してはいけないシークレットキー・制限付きキーを区別しています。制限付きでも秘密情報である点は変わりません。Stripeの公式キー分類
| 確認するもの | 判断の入口 |
|---|---|
| 公開可能キー・クライアント識別子 | 発行元が配布アプリへの掲載を認めているか。サーバー側の権限確認はどう行うか |
| シークレットキー・秘密鍵・長期トークン | 配布物に入っていないか。誰が何を実行できる権限か |
| URL・アプリの識別子 | 値が見えることと、不正な操作を許してよいことを分ける |
この表は点検用の整理です。Stripeのキー接頭辞や分類を、別サービスへそのまま当てはめることはできません。
認証と認可を分けて点検する
認証は「誰がアクセスしているか」、認可は「その利用者が、そのデータに、その操作をしてよいか」の確認です。アプリ内の署名処理や難読化だけに依存せず、サーバーで対象と操作に応じた権限を確かめます。
JPCERT/CCは、レート制限と異常なリクエストの監視、外部URLを取得するAPIの宛先制限も挙げています。外部URLではリダイレクト後の宛先も検証する必要があります。推奨対策の説明
秘密情報を公開してしまった場合
GitHubの公式ガイドは、パスワードやトークンなどの秘密情報が露出した場合、まず失効またはローテーションを行うよう説明しています。ファイルを削除することと、露出した認証情報を使えなくすることは別の作業です。GitHubの漏えい対応ガイド
対応担当者は、利用中のサービスを把握して、発行元の手順に沿った失効・再発行と置き換えを進めます。Gitの履歴を書き換える場合は、共同作業者のコピーや既存の作業への影響もあるため、独断で進めず調整します。
開発チームで最初に確認する5点
以下はTesuji編集上の点検案です。
- 配布するアプリ・ブラウザー向けコードに、秘密鍵や長期トークンが含まれていないか。
- キーごとの用途・権限・管理者・利用先を説明できるか。
- APIごとに、利用者と操作対象に応じた権限を確認しているか。
- 異常な利用に気づくログや監視があり、担当者が確認できるか。
- キーが露出した際、失効と置き換えを誰が判断・実施するか。
確認日：2026年10月28日。個別のキーの公開可否・失効方法は、発行元の公式仕様で確認してください。