AI APIキーの置き場所：ブラウザに秘密を埋め込まない

ブラウザへ送ったコードは、利用者から見える

ブラウザが受け取ったHTMLやJavaScript、自分のブラウザとサーバの通信内容は、開発者ツールで確認できます。フロントエンドのコードに秘密のAPIキーを書くと、そのキーも利用者に渡してしまいます。

ファイル名を分かりにくくしたり、コードを圧縮したりしても、キーを秘密にすることはできません。フロントエンド用の環境変数に設定した場合も、ビルドで公開するコードへ展開されれば、利用者から見える状態になります。

ブラウザ → 自分のサーバ → AI API

秘密キーを取り扱うWebアプリケーションでは、キーを自社が管理するサーバ側にのみ配置し、ブラウザからのリクエストは一度自社のバックエンドAPIで受け取ります。サーバ側でユーザー認証や入力内容の安全性を確認した上で、サーバからAIプロバイダのAPIを呼び出します。

サーバ環境で環境変数からキーを読み込む構成にすれば、Gitで管理するソースコード自体にキーの文字列を書き込まずに済みます。ただし、環境変数は安全な保管場所の選択肢のひとつに過ぎず、それ単体で外部からの不正アクセスをブロックできるわけではありません。

// サーバ側だけで実行する例。実際のキーはコードに書かない。
const apiKey = process.env.AI_API_KEY;
if (!apiKey) {
  throw new Error('AI_API_KEY is not configured');
}
// 利用者と入力を確認してから、サービス指定の方法で送信する。

上記のコード片は、サーバサイドで環境変数を安全に取得する実装イメージを示したものです。APIを叩く処理の完成版コードではありません。実際のエンドポイント呼び出しやリクエストヘッダーの形式は、利用するプロバイダの公式仕様に沿って実装してください。

サーバを経由させても、APIの呼び出し制限は不可欠

APIキーをサーバ内に隠蔽しても、そのバックエンドエンドポイントが誰でも無制限に叩ける状態になっていれば、悪意ある第三者にプロキシとして悪用され、高額な請求が発生する危険が残ります。キーの存在を隠すことと、機能の利用を正当に制限することは、別個のセキュリティ対策です。

• 誰が呼び出しているかを、ログインや利用条件で確認する。
• 入力の長さや、1回の出力上限を決める。
• 利用者ごと、時間帯ごとの呼び出し回数を制限する。
• 利用量を記録し、費用が増えたときに気付けるようにする。

CORS（Cross-Origin Resource Sharing）を設定しただけでは、外部からの不正リクエストを遮断できません。CORSは一般的なブラウザによる越境通信を制限する仕組みに過ぎず、curlなどのCLIツールやスクリプトを使えば容易に迂回されてしまいます。自社のバックエンドサーバ側でユーザー認証とレートリミットを確実に制御しましょう。

Gitリポジトリやログ出力へのキー混入を防ぐ

秘密情報を含む設定ファイルをGitへ入れないよう、除外する設定を用意します。一度コミットしたキーは、後からファイルを削除しても履歴に残っている場合があります。

ログへの出力にも注意が必要です。リクエストのヘッダーや環境変数を丸ごと記録すると、キーまで残ることがあります。障害を調べるときも、必要な情報だけを記録し、秘密値は出さないようにします。

開発用と公開用のキーは分けて管理します。サービスが対応していれば、権限や使用先の制限も設定してください。不要になったキーは停止し、どのアプリがどのキーを使っているか把握しておきましょう。

万が一キーが漏えいした際は、即座に無効化・再発行を行う

APIキーがGitHub等の公開領域に流出してしまった場合は、単にコードを修正して再デプロイするだけでは対処になりません。すでに第三者によってキーが複製・保存されているリスクを想定し、旧キーの即時無効化と新キーへの移行作業を迅速に行います。

1. 該当するキーを、サービスの管理画面で無効にします。
2. 利用履歴や請求に、覚えのない呼び出しがないか確認します。
3. 新しいキーを安全な設定先に入れ、必要なアプリを更新します。
4. 漏れた場所を調べ、同じ経路で再び公開されないよう直します。

Webアプリケーションを一般公開する前には、実際にブラウザに配信されるJavaScriptファイル群や公開ディレクトリの設定ファイルを見渡し、意図しない秘密情報が含まれていないか総点検しましょう。動作検証用のサンプルコードであっても、本番環境のキーを直書きしたまま公開することは厳禁です。