1,000万サイトを調べたら、使える鍵が1,748本。ソースを見ても見つからない場所にあった

• 1,000万のWebサイトを調べ、実際に使えるAPIキーが1,748件見つかった
• 8割以上はJavaScriptの中。その6割は「組み立てた後のファイル」にだけあり、元のソースを調べても見つからない
• 鍵は平均12か月放置。知らせても無効化まで行ったのは26%だった

Webサイトを開くと、ブラウザは画面を作るためのファイルを大量に受け取る。そのファイルは、誰でも中身を読める。

その中に、本来は裏側に隠しておくべき「APIキー」がどれくらい混ざっているのか。米スタンフォード大学などの研究チームが、1,000万のサイトを調べた結果を論文にまとめた。題名は「Keys on Doormats（玄関マットの下の鍵）」。セキュリティ分野の主要な国際会議CCS 2026に採択されている。

APIキーは、外部のサービスを使うときの合鍵だ。クラウドのサーバー、決済、メール配信、AIなどを、その鍵を持つ人の権限で操作できる。

200万件の候補から、本物が1,748件

研究チームが使ったのは、HTTP Archiveという公開データだ。Chromeでよく見られているサイトを実際に表示し、読み込まれたファイルと通信をすべて記録したもので、2025年9月分を使っている。対象は約1,190万のホスト名、約930万のドメインになる。

ここから鍵の形をした文字列を探すと、約200万件の候補が出た。ただし大半は、鍵に似ているだけの別の文字列だった。

そこで、14のサービスについてその鍵が今も使えるかを、データを読み書きしない確認用の窓口で一つずつ確かめた。残ったのが1,748件だ。9,804サイト・5,693ドメインで見えていた。

論文は、これが下限だと強調している。調べたのは14サービスだけで、確認の時点ですでに無効になっていた鍵は数えていない。トップページしか見ていない、という制約もある。

ソースを見ても見つからない理由

この研究でいちばん大事なのは、鍵がどこにあったかだ。

• 84%がJavaScriptのファイルの中
• HTMLが8%、JSON（データのファイル）が7%
• JavaScriptの中の62%は、ビルドで組み立てた後のファイル（バンドル）にだけあった
• 16%は、外部から読み込んだ部品（タグ管理やCDNなど）経由だった

今のWebサイトの多くは、書いたプログラムをそのまま置くのではない。ビルドという工程で、たくさんのファイルを1つにまとめ、軽くしてから公開する。

このとき、設定ファイルにある「環境変数」の値が本物の文字に置き換えられて埋め込まれる。設計図には「ここに鍵の名前」としか書いていないのに、完成品には鍵そのものが入る。

多くの組織は、鍵の流出をソースコードの検査で防ごうとしている。だが設計図をいくら調べても、完成品にしか現れない鍵は見つからない。論文が「実際に表示されたサイトを調べる必要がある」と言っているのは、この点だ。

隠したつもりでも読める

見つかった鍵の67%はそのままの文字で置かれていた。残りはBase64などに変換されていたが、これは誰でもすぐに元に戻せる。

回答した組織の中には、検査ツールに引っかからないように変換していたと書いてきたところもあったという。隠したのは検査ツールからで、攻撃者からではない。

現場が答えた「混ざった理由」

研究チームは、鍵を見つけた組織に知らせ、原因を尋ねた。40の組織が理由を答えている（複数回答）。

• ビルドの設定ミス。公開してよい変数だけに付ける決まった頭文字（NEXT_PUBLIC_ など）の仕組みが、プラグインのせいで効かず、すべての環境変数が埋め込まれた
• 名前の付け間違い。裏側だけで使う鍵に、公開用の名前を付けてしまった
• 試験のときに入れた鍵が残った。前任者のコードを丸ごと引き継いで、気づかなかった
• 「読むだけの鍵だから安全」と思っていた。確かめると、実際はもっと広い権限があった

答えた組織のうち、7割は「うっかり」だったとしている。そして指摘を認めた53組織のうち39は、知らせを受けるまで気づいていなかった。

1本の鍵で、どこまで届くか

論文は、鍵1本の影響の大きさも具体的に示している。

• 見つかったGitHubの鍵119本で、9,720のリポジトリに手が届いた。うち4,270は非公開。1本で3,496のリポジトリを操作できる鍵もあった
• 世界の金融システムに重要とされる大手銀行（G-SIB）のAWSの鍵。データベースや、ほかの鍵を保管する仕組みまで操作できた
• ドローンや玩具に使われる無線機のファームウェア開発者の鍵。配布する更新ファイルを書き換えられる状態だった
• 国のエネルギー事業者、学校の安全管理、警察と裁判所のシステムの鍵

いずれも、研究チームの連絡のあとに鍵は削除または無効化された。返事をしないまま、黙って無効化したところもある。

放置は平均12か月。知らせても「消すだけ」

過去のデータをさかのぼると、鍵は平均12か月、長いものは5年見えたままだった。何もしなければ、1か月で減るのは1割ほどだ。

研究チームは2,435の組織に、のべ9,746通のメールを送った。58%は宛先がなく戻ってきた。届いたのは7割ほどのサイトになる。

結果、14日で公開ファイルから鍵が消えたのは約半分。だが鍵そのものを無効にしたのは26%にとどまった。

この差は大きい。ファイルから消しても、鍵はまだ使える。検索エンジンのキャッシュや、アーカイブのサイトに古いファイルは残る。すでに誰かが写していれば、それで終わりだ。

さらに172日後に調べ直すと、公開ファイルに鍵がある件数は、むしろ増えていた。一度消したのに、次の更新でまた混ざったとみられる。

このサイトでは以前、開発用のクラウドから鍵が盗まれた件や、外部サービスの鍵を利用者が自分で替えるしかなかった件を書いた。鍵は、消すのではなく替える。ここはどの件でも同じだ。

AIで作るときに気をつけたいこと

ここからは筆者の見方だ。

OpenAIの鍵が181件見つかっている。外部の部品から見えていた割合も、サービスの中でOpenAIとTwilioがいちばん高い（24%）。

AIに「画面からChatGPTを呼ぶ機能を作って」と頼むと、ブラウザから直接AIのAPIを呼ぶコードが出てくることがある。動くし、早い。だがそれは、鍵をブラウザに渡す形だ。

ブラウザで動くコードに入れたものは、全部見えると考えたほうがいい。鍵を使う処理は、自分のサーバー側に置いて中継させる。論文もこの方法を勧めている。

自分のサイトで確かめる

1. 公開している完成品を調べる。ソースではなく、ビルドした後のファイルが対象だ。論文は、鍵の検出ツール（TruffleHogやGitleaksなど）をビルドの工程に組み込み、見つかったら公開を止めることを勧めている
2. 環境変数は「公開してよいもの」だけを名指しで通す。頭文字の決まりに任せず、使っているプラグインがそれを壊していないかも見る
3. 鍵を使う処理はサーバー側へ。ブラウザに鍵を渡さない
4. 見つけたら、まず無効化して作り直す。ファイルから消すのはその後でいい
5. 試験用と本番用の鍵を分ける。試験の鍵が残っても、被害が小さく済む

コードや設定をAIに貼って相談するときも、鍵が混ざっていないかは見ておきたい。このサイトのAIに貼る前の個人情報チェックは、APIキーやパスワードらしき文字列も見つけて伏せ字にする（文章はブラウザの外に送らない）。

まとめ

• 1,000万サイトから、使えるAPIキー1,748件。14サービスだけの下限
• 84%はJavaScript。その62%は組み立て後のファイルにだけあり、ソースの検査では見つからない
• 原因はビルドと環境変数の設定ミス、名前の付け間違い、試験の鍵の消し忘れ
• 鍵は平均12か月放置。知らせても無効化は26%
• 消すのではなく、無効化して替える。鍵を使う処理はサーバー側に置く

出典

• Nurullah Demir, Yash Vekaria, Georgios Smaragdakis, Zakir Durumeric「Keys on Doormats: Exposed API Credentials on the Web」（arXiv、2026年9月14日の第3版。ACM CCS ’26 採択。本文の数字はすべてこの論文による）
• ITmedia NEWS「1000万のWebサイトで『生きたAPIキー』が大量に“丸見え”状態？」（2026年10月24日配信）

本記事は2026年10月24日時点で公開されている論文の内容に基づく。論文は特定の組織名を公表しておらず、本記事も扱わない。「AIで作るときに気をつけたいこと」の節は筆者の見方である。