フロントエンドのAPIキー露出とは？危険性や対策方法を徹底解説

APIキーをフロントエンドに置くと何が起きるのか

ブラウザへ配信した時点で、その値は閲覧・複製される前提になります

フロントエンドの API キー露出とは、ソースコードに秘密を書いたことだけを指しません。実際には、bundle へ埋め込まれた環境変数、client-side から直接叩いている API、デバッグ用の設定ファイル、公開された JavaScript から読み取れる値すべてが対象です。つまり問題の本質は、ブラウザへ配るものに秘密を載せてしまう設計にあります。

一度ブラウザへ渡した値は、表示画面から直接見えなくても、通信内容、配信物、エラーメッセージ、ソースマップ、キャッシュなどを通じて複製される前提で考える必要があります。だから front-end 実装では、「見えにくくしているから大丈夫」ではなく、配った時点で公開物になるという前提に立たなければなりません。

既存の 公開リポジトリの情報漏えいとは？ はソース管理上の秘密露出を主役にしていますが、本記事の主役はそこではありません。リポジトリが private でも、デプロイされた front-end が secret を含んでいれば事故は起きます。つまり API キーのフロントエンド露出は、repo leak とは別の設計ミスです。

直叩きで動いて見えることが、実装ミスを正当化しやすくします

フロントエンドから API を直叩きすると、開発初期は非常に楽に見えます。認証、proxy、サーバ側の実装を省いて、画面からすぐ結果を出せるからです。とくに LLM を使った高速実装では、「まず動かす」ことが優先され、配信物へ secret を含めてもその場では問題が見えにくいため、そのまま本番へ近づきやすくなります。

しかし、その楽さは secret をブラウザへ渡す代償で成り立っていることが少なくありません。検索 API、生成 AI API、課金 API、管理 API のように権限や利用量に直結する呼び出しは、front-end の直叩きと相性が悪いです。つまり「すぐ動いた」は安全性の証拠ではなく、むしろ境界の設計が抜けているサインであることがあります。

もう一つ見落とされやすいのは、front-end に置いた値が第三者にそのまま再利用されることだけではなく、利用量や課金、レート制限、検索対象、モデル利用条件といったサービス利用の責任まで奪われることです。つまり API キー露出は、秘密が見える問題であると同時に、利用主体の境界が崩れる問題でもあります。

どの値は公開されてもよく、どの値は絶対に置いてはいけないのか

publishable key と secret key の境界を曖昧にしないことが出発点です

front-end に置ける値がゼロというわけではありません。たとえば、公開前提で設計された publishable key や、origin 制限・機能制限が強くかかっている識別用の値は、条件付きで配信可能なことがあります。ただし、それは「公開しても問題が起きないように設計された値」であることが前提です。代理実行権限や課金権限を持つ secret とは意味がまったく違います。

OpenAI の API key safety↗でも、API キーは client-side application に置かず、server-side へ保持すべきと明確に示されています。これは OpenAI に限らず、権限の強い key 全般に当てはまる原則です。front-end に置いてよいかどうかは、文字列の見た目ではなく、その値で何ができるかで判断してください。

とくに client secret、管理者権限を持つ API key、サーバ側代理実行に使う token は、front-end へ置いてはいけません。これらは「見られると困る」ではなく、見られた瞬間に悪用前提になる値です。UI から直接見えなくても、配信物や通信で届く時点で不適切です。

制限設定がある key でも、責任境界を曖昧にしたまま使うと危険です

Google Maps Platform のように、referer 制限や API 制限を前提に front-end で使う設計があるサービスもあります。こうした key は、Google の best practices↗ が示すように、利用先制限、API 制限、監視、ローテーションを前提にして初めて安全性が成り立ちます。つまり「front-end に置ける」のではなく、制限を入れたうえで公開してもよいように設計されているのです。

ここでありがちな失敗は、「一部のサービスで front-end 利用が許されるから、他の key も同じ感覚で置いてよい」と拡大解釈することです。この誤解が、検索 API、生成 AI API、管理 API をそのまま browser から叩く実装につながります。公開可能な key は例外であり、基本は server-side へ寄せる と考えた方が事故を減らしやすくなります。

とくに開発現場では、「課金は少ないから」「PoC だから」「利用者は社内だけだから」という理由で境界が緩みやすいです。しかし front-end に置いた時点で、その値は環境の内外に関係なく公開物です。安全性は利用者の善意ではなく、値に与えた権限と利用制限の強さ で決まると考えた方が、判断を誤りにくくなります。

実務では、どの key が公開前提で、どの secret が絶対非公開かを一覧化していないチームほど事故が起きやすいです。レビュー時に毎回口頭で判断していると、人が変わった瞬間に基準が揺れます。だから front-end の API キー露出対策では、公開可能な値の定義を文章で固定することも、実装と同じくらい重要です。

なぜ LLM 開発ではフロント直叩きが増えやすいのか

見た目の完成を急ぐと、秘密の置き場所が後回しになります

LLM を使った開発では、UI の雛形、API 呼び出し、状態管理、デプロイ設定まで一気に作れるため、短時間で「それらしく動くもの」ができます。その一方で、境界設計、認証、proxy、key 管理のような地味な部分は、生成されたコードの後処理として後回しにされやすくなります。これが front-end API 直叩きが増える大きな理由です。

とくに、プロトタイプから本番へ移行する過程で、「この key は後で入れ替えるつもりだった」「検証用だから一旦 front に置いた」が残りやすくなります。LLM は動く実装を素早く出せますが、そのままでは責任境界まで設計してくれるわけではありません。だから人間側が「何を browser に置かないか」を先に決めておく必要があります。

既存の シャドーAPIとは？ が扱うように、未管理 endpoint が増えると API の可視性自体が落ちます。front-end 直叩きは、その未管理化をさらに進めやすく、どの API が誰の責任で、どの secret がどこにあるかを曖昧にします。つまり問題は speed そのものではなく、実装速度に対して責任分界の設計が追いつかないことです。

サンプルコードの流用が、そのまま production 設計になることがあります

LLM が出すコードや公式サンプルは、学習用・検証用として最短動線を優先していることがあります。そこに含まれる key の扱い、直叩き構成、簡易的な認証の前提を理解せずに production へ持ち込むと、配信物に secret が残ります。つまりサンプルは便利ですが、sample path と production path は別 と認識しなければ危険です。

そのため、LLM 開発では「サンプルが動いた」時点で設計を確定させず、server-side へ寄せるべき処理、制限付きで公開してよい値、代替手段としての BFF を必ず見直してください。ここをレビュー工程に組み込まないと、後から key rotation を回すよりも先に abuse が起きる可能性があります。

実務では、生成 AI の呼び出し、検索、地図、決済、分析タグ、feature flag など、front-end が関わる外部接続は一つではありません。だから code review でも「API キーがあるか」だけを見るのではなく、どの外部サービスへ、どの権限で、どの画面から出ていくか を設計レビューの観点に入れる必要があります。LLM 開発を安全にするには、速度より先に境界の質問を固定することが効果的です。

BFF / proxy / key restriction / rotation をどう組み合わせるか

権限の強い処理は BFF や proxy へ寄せて、front-end は最小化します

BFF は Backend for Frontend の略で、front-end から直接 third-party API を叩かず、アプリ専用の server-side を間に置く考え方です。重要なのは名前より、権限の強い呼び出しを browser から切り離すことです。課金、生成、管理、検索、レート制御が必要な処理は、front-end で秘密を持つより proxy へ寄せた方が安全です。

proxy を入れると、利用者認証、入力検証、利用量制御、監査ログ、key rotation を一か所へ集めやすくなります。逆に front-end 直叩きでは、これらの管理をそれぞれの browser session に分散させることになり、運用が崩れやすくなります。API キー露出対策は secret を隠す話ではなく、権限と責任を server-side へ戻す設計です。

制限設定とローテーションは『流出しない前提』ではなく『流出しても縮小できる前提』で使います

referer 制限、origin 制限、IP 制限、API 制限、使用量上限、監査ログ、ローテーションは、流出しないことを保証するものではありません。むしろ、流出しても悪用範囲を狭めるための設計です。制限を前提にしない publishable key は、公開可能な設計とは言いにくくなります。

GitHub の leaked secret remediation ガイドが示す通り、秘密が外へ出たら最終的には失効と置き換えが必要です。だから最初から、失効しても復旧しやすい命名、環境分離、切り替え手順、通知先を持っておくべきです。front-end の API キー露出対策は、「漏れたら慌てる」ではなく、漏れてもすぐ切り替えられる運用を作るところまで含みます。

また、BFF を置いたから終わりではなく、その BFF 自体の認証、レート制御、ログ、権限分離、出力制御も必要です。front-end API キー露出対策は、単に secret の置き場所を動かす話ではなく、責任境界ごとに制御を置き直す設計です。ここを誤ると、表面上は server-side 化しても、実質的には同じ危険を別の場所へ移しただけになります。

その意味で、front-end の API キー露出対策は「client-side をゼロにする」話ではありません。front-end で持ってよい識別情報、server-side に寄せるべき秘密、監査対象になる接続を整理し、責任境界に応じて制御を分配することが目的です。ここまで整理できると、実装速度と安全性を両立しやすくなります。

実務では、この整理を設計書やレビュー項目に落とし込んでおくと、開発者が変わっても front-end へ置いてよい値の判断がぶれにくくなります。つまり対策の中心は、技術実装と同時に基準を固定することです。

境界が文章で残っていない実装は、次の改修で同じ誤りを繰り返しやすくなります。

漏えい後の初動で何を確認すべきか

失効より先に、どの配信物とどの API が露出していたかを切り分けます

実際に front-end へ置いた API キーの露出が疑われたときは、まず失効だけで終わらせないでください。bundle に埋め込まれていたのか、ログに出たのか、公開リポジトリにも残っているのか、どの API の呼び出し権限を持っていたのかを切り分ける必要があります。ここを曖昧にすると、同じ秘密が別の場所に残って再発します。

そのため、初動では「どの値が漏れたか」だけでなく、「どの front-end 配信物に入っていたか」「どの origin から使える設定だったか」「どの third-party API に到達できたか」を整理してください。つまり見るべきなのは key 単体ではなく、その key を使える公開面全体です。

公開面の棚卸しとログ確認を同時にやると再発防止につながります

API キー露出の事故は、秘密が漏れた瞬間より、どの公開面から再発するかが見えないまま終わる方が危険です。公開 bundle、古い staging、サンプルページ、デバッグ用 host、未管理 API が残っていると、同じ構造で再発します。だから incident の後は、キーの失効と公開面の棚卸しを同時にやる必要があります。

既存の SaaS台帳管理とは？ や 外部接続点は見えているか？ の考え方を重ねると、front-end から third-party API へ出ていく経路や、サンプルページを含む外部公開面が整理しやすくなります。再発防止の中心は、秘密の管理だけでなく、公開されている接点の管理です。

さらに、漏えい後のレビューでは「なぜその key を front-end に置いたのか」も振り返る必要があります。開発速度を優先したのか、BFF の準備が間に合わなかったのか、サンプルコードをそのまま持ち込んだのか、審査が重くて抜け道を作ったのかで、再発防止策は変わります。原因を個人の不注意だけにすると、同じ設計ミスが別の画面で再発しやすくなるためです。

ASM診断 PROで公開面の見直しを始めるなら

ASM診断 PRO は API キーそのものを vault 管理する製品ではありませんし、front-end のソースコード解析専用のツールでもありません。それでも実装ミスの再発防止に有効なのは、どの公開面が外から見えているか を外部観点で整理できるからです。client-side 直叩きの事故では、bundle を配信している host、古い staging、サンプルページ、未管理 API、公開管理面が同時に残っていることが少なくありません。

ASM診断 PRO を起点にすると、公開中の login page、API host、古い subdomain、用途不明の外部接点を洗い出し、「どこに secret を置いてはいけないか」だけでなく、「どこからその実装が外へ出ているか」を確認しやすくなります。front-end の API キー露出対策は、キーの取り扱いルールだけでなく、外に公開されている接点の棚卸し と組み合わせて初めて運用へ落ちます。

とくに、公開リポジトリの情報漏えいとは？ や シャドーAPIとは？ とあわせて見ると、コード、配信物、API、管理面のどこに秘密や責任境界のミスが残っているかを横断して確認しやすくなります。API キー露出を単発の失効作業で終わらせず、外部公開面と接続先まで見直したいなら、まずは 今どの host と導線が外へ出ているか を可視化するところから始めてください。

よくある質問（FAQ）

フロントエンドに置いてよい API キーはありますか

ありますが、公開前提で設計され、origin や API の制限が強くかかっている値に限るべきです。代理実行や課金権限を持つ secret は front-end に置いてはいけません。

難読化していれば secret を front-end に置いても安全ですか

いいえ。難読化は閲覧を遅らせるだけで、配信した時点で複製前提です。安全性の中心は、公開してよい値かどうかと、権限境界を server-side に戻せているかです。

LLM 開発でなぜ front-end 直叩きが増えるのですか

動くものを短時間で作れる一方、境界設計や proxy の実装が後回しになりやすいからです。サンプルコードの便利さが、そのまま production 設計へ持ち込まれることもあります。

漏えいが疑われたら最初にやることは何ですか

key の失効だけでなく、どの配信物、どの API、どの origin から使えたかを切り分けてください。同じ構造が残っていると、置き換えても再発します。

BFF を置けば必ず安全ですか

いいえ。BFF は責任境界を整理しやすくしますが、制限設定、監査、ローテーション、外部公開面の整理と組み合わせて初めて効果が安定します。

まとめ

フロントエンドの API キー露出は、単なるコーディングミスではなく、配信物に何を載せてよいかという設計判断の問題です。公開リポジトリに secret を置いていなくても、browser へ配る bundle に秘密を含めていれば事故は起きます。だから本質は「見えないようにする」ことではなく、front-end に渡してよい値と、絶対に server-side へ残す値の境界を明確にすることにあります。

とくに LLM を使った高速実装では、直叩きで画面を動かすことが容易になる一方、proxy や BFF、監査、ローテーション、公開面の棚卸しが後回しになりやすいです。その結果、動いて見える実装がそのまま production へ近づき、後から key 失効や構成変更で苦しむことになります。対策としては、publishable key と secret を厳密に分け、権限の強い呼び出しを server-side へ寄せ、制限設定とローテーションを最初から設計へ組み込むことが重要です。

そして再発防止では、コードだけでなく公開面を見る必要があります。front-end がどの host から配信され、どの API へ出ていき、どの staging やサンプルページが残っているのかを確認しなければ、同じ構造でまた秘密が外へ出ます。つまり API キー露出の対策は、secret management 単体ではなく、外部公開資産と接続点を含めた運用設計として考えるべきです。そこまで見直せて初めて、「front-end に置いてはいけないものを置かない」状態を継続しやすくなります。