WebサイトにAPIキーが公開されてしまう問題
2026年10月、スタンフォード大学などの研究者による論文「Keys on Doormats: Exposed API Credentials on the Web」が話題になりました。
ITmedia NEWSの記事によると、研究チームが1,000万のWebサイトを対象に調査した結果、AWS、Stripe、GitHub、OpenAIなど14のサービスに関連する有効なAPIキー1,748件が、5,693のドメインで露出していたといいます。
特に注目したいのは、露出したキーの84％がJavaScriptファイル内にあり、その多くがビルド時に生成されたファイルに含まれていたという点です。
つまり、開発者がソースコードに直接APIキーを書いていなくても、Webサイトを公開するまでの工程で秘密情報が表に出てしまうことがあります。
参考：ITmedia NEWS「1000万のWebサイトで『生きたAPIキー』が大量に“丸見え”状態？」
APIキーの漏えいは、大規模なサービスだけの問題ではありません。個人で運営するWebサイトでも、外部APIとの連携やサーバーの設定を誤れば、同じ問題が起こり得ます。
重要なのは、APIキーをソースコードに直接書かないことだけではなく、秘密情報がどこで管理され、どの段階で利用され、最終的にどこへ出力されるのかを把握することです。
APIキーを公開してはいけない理由
APIキーやアクセストークンは、外部サービスを利用する際の認証やアクセス制御に使われます。
キーの種類や権限によっては、第三者に知られることで次のような被害につながります。
- 外部APIを不正に利用され、従量課金の料金が発生する
- データベースやストレージに不正アクセスされる
- 外部サービスのアカウントやデータを操作される
- 個人情報や業務データを取得される
- サービスの停止や、利用制限につながる
ただし、すべてのAPIキーが同じように危険というわけではありません。
たとえば、決済サービスの公開用キーや、利用範囲を制限した地図サービスのキーなど、ブラウザでの利用を前提としたキーもあります。
問題になるのは、本来サーバー側だけで使うべき秘密鍵や、広い権限を持つアクセストークンなどが公開されることです。
公開用のキーであっても、利用元のドメインやAPIの種類、利用量などを制限できる場合は、適切に設定しておく必要があります。
APIキーが公開状態になってしまう主な原因
1. ソースコードに直接書いている
最も分かりやすいのは、APIキーをソースコードに直接記述するケースです。
const apiKey = "your-secret-api-key";
このコードが公開リポジトリにアップロードされたり、フロントエンドのJavaScriptに含まれたりすれば、キーを第三者に取得される可能性があります。
開発中のテスト用コードをそのまま本番環境に持ち込んでしまうケースにも注意が必要です。
2. .envを使っていても、ビルド時に公開される
APIキーを.envファイルで管理する方法は、一般的な対策のひとつです。
しかし、.envに記述すれば必ず安全になるわけではありません。
フロントエンドのビルドツールやフレームワークには、ビルド時に環境変数の値をJavaScriptへ埋め込む仕組みがあります。
たとえば、ViteではVITE_、Next.jsではNEXT_PUBLIC_、AstroではPUBLIC_など、公開を意図した環境変数の命名規則が使われます。
次のような設定を考えてみます。
VITE_API_KEY=your-secret-api-key
この変数をフロントエンドのコードから参照すると、ビルド後のJavaScriptに実際の値が埋め込まれる場合があります。
const apiKey = import.meta.env.VITE_API_KEY;
ビルドが完了すると、元のソースコードに.envの内容が直接書かれていなくても、生成されたJavaScriptにはキーが含まれている可能性があります。
ブラウザで実行されるJavaScriptは、利用者が開発者ツールや通信データを使って確認できます。難読化や圧縮を行っていても、秘密情報を隠す対策にはなりません。
サーバー側で使う秘密情報には、フロントエンドへ公開される環境変数の接頭辞を付けないことが基本です。
3. GitHubなどのリポジトリへ誤ってアップロードする
.envファイルを利用する場合は、Gitなどのバージョン管理システムに登録しないよう設定します。
たとえば、.gitignoreには次のように記述できます。
.env
.env.*
!.env.example
ただし、この設定では.env.example以外の.env.*ファイルも無視されるため、プロジェクトによっては必要な設定ファイルまで対象になる可能性があります。
実際の運用では、追跡対象とするファイルを確認し、必要に応じて除外ルールを調整してください。
また、.env.exampleには変数名とダミー値だけを記述し、実際のAPIキーやパスワードを含めないようにします。
# .env.example
API_KEY=replace-with-your-api-key
DATABASE_URL=replace-with-your-database-url
注意したいのは、.gitignoreを設定するだけでは、すでにGitの追跡対象になっているファイルを除外できないことです。
一度コミットしたファイルは、その後に削除してもGitの履歴に残る場合があります。公開リポジトリに秘密情報を登録してしまった場合は、ファイルを削除するだけでなく、漏えいしたキー自体を無効化・再発行する必要があります。
4. ビルド済みのファイルや公開ディレクトリに秘密情報が含まれている
ソースコードを確認しただけでは、秘密情報の露出を完全には防げません。
ビルド工程で生成されるJavaScript、設定ファイル、ソースマップ、デバッグ用ファイルなどに秘密情報が含まれる可能性があるためです。
また、サーバー側で管理しているつもりでも、設定ファイルやバックアップファイルをWeb公開ディレクトリに配置していれば、外部から取得できる状態になることがあります。
たとえば、Webサーバーの公開ルートに.envやデータベースの接続情報を置く構成は避けるべきです。
ファイルへの直接アクセスを制限する設定だけに頼らず、そもそも公開対象となるディレクトリに秘密情報を配置しない設計が重要です。
5. CI/CDやデプロイの設定で漏れる
GitHub Actionsなどを使って自動デプロイする場合も注意が必要です。
リポジトリに秘密情報を直接書かなくても、ビルド時に環境変数を渡す方法によっては、フロントエンドの成果物へ値が埋め込まれることがあります。
また、デバッグ用の出力やビルドログ、エラーメッセージなどに秘密情報が含まれてしまう可能性もあります。
自動デプロイを導入する場合は、秘密情報をCI/CDのシークレット機能などで管理するだけでなく、ビルド工程でその値がどのように利用されるのかを確認する必要があります。
.envでの管理とサーバー側での利用
一般的なWebサイトでは、秘密情報をソースコードから分離し、環境変数やサーバー側の設定として管理する方法が使われます。
ローカル開発では.envファイルに値を記述し、サーバー側の処理から参照する構成がその一例です。
API_KEY=your-secret-api-key
Node.jsであれば、環境変数を次のように参照できます。
const apiKey = process.env.API_KEY;
この例では、API_KEYの値がサーバー側の実行環境に設定されていることを前提としています。
.envファイルを読み込む仕組みは、Node.jsのバージョンや利用するフレームワーク、実行環境によって異なります。
また、環境変数として管理する場合でも、次の点には注意が必要です。
.envファイルをGitの追跡対象にしない- 本番環境では、可能ならホスティングサービスやサーバーの設定画面から値を管理する
- APIキーをログやエラーメッセージに出力しない
- 必要以上に強い権限をキーに付与しない
- 開発環境、検証環境、本番環境でキーを分ける
- フロントエンドから参照される変数に秘密情報を入れない
ここで大切なのは、.envそのものが秘密情報を暗号化してくれるわけではないという点です。
.envは設定値をソースコードから分離するためのファイルであり、アクセス権限やファイルの配置、バージョン管理の設定が適切でなければ、情報漏えいを防ぐことはできません。
Cloudflare WorkersならSecretsで管理できる
Cloudflare Workersを利用する場合は、WorkersのSecrets機能を使ってAPIキーやアクセストークンなどの秘密情報を管理できます。
通常の環境変数と異なり、Secretsは秘密情報を扱うための仕組みで、設定後の値はCloudflareのダッシュボードやWranglerから通常の方法では表示されません。保存時の暗号化も行われます。
ダッシュボードから設定する
Cloudflareのダッシュボードでは、対象のWorkerを開き、設定画面の「Variables and Secrets」から値を登録できます。
秘密情報を登録するときは、通常の変数ではなく、種類としてSecretを選択します。
たとえば、次のような名前で登録します。
OPENAI_API_KEY
値には実際のAPIキーを設定します。
登録した秘密情報は、Workerのコードから環境変数と同じように参照できます。
export default {
async fetch(request, env) {
const apiKey = env.OPENAI_API_KEY;
// ここでAPIキーを使ってサーバー側からAPIを呼び出す
// APIキー自体はレスポンスに含めない
return new Response("OK");
}
};
これは構造を示すための簡単な例です。実際には、受け取ったリクエストの検証や、外部APIへのリクエスト処理、エラー処理などを実装します。
重要なのは、秘密情報をブラウザに渡すのではなく、Workerの実行環境内で利用することです。
Wranglerから設定する
コマンドラインツールのWranglerを使う場合は、次のコマンドでSecretを登録できます。
npx wrangler secret put OPENAI_API_KEY
コマンドを実行すると値の入力を求められるので、実際のAPIキーを設定します。
この方法なら、秘密情報をソースコードや設定ファイルへ直接記述せずに管理できます。
一方、wrangler.tomlやwrangler.jsoncなどにある通常のvars設定は、秘密情報を保存するための仕組みではありません。APIキーやパスワードなどを通常の変数として記述せず、Secretsを利用する必要があります。
ローカル開発では.envや.dev.varsを使う
Cloudflare Workersのローカル開発では、.dev.varsや.envを利用して秘密情報を設定できます。
たとえば、.dev.varsに次のように記述します。
OPENAI_API_KEY=your-secret-api-key
これらのファイルはGitの追跡対象にせず、.gitignoreで除外します。
本番環境のSecretとローカル開発用の値は分けて管理し、開発環境で使っているキーがそのまま本番環境へ持ち込まれないようにすることも重要です。
Cloudflare WorkersのSecretsについては、公式ドキュメントで詳しく説明されています。
AWSではSecrets Managerなどを利用する
AWSでも、APIキーやデータベースの認証情報を安全に管理するための仕組みが用意されています。
代表的なものがAWS Secrets Managerです。
Secrets Managerでは、認証情報などの秘密情報を保管し、必要なアプリケーションから取得できるようにします。保存された秘密情報はAWS KMSを利用して暗号化でき、アクセス権限の制御や監査、認証情報のローテーションなどにも対応しています。
AWS Lambdaなどで外部APIを利用する場合も、アプリケーションのソースコードへキーを直接記述するのではなく、Secrets Managerなどから必要な値を取得する構成が選択肢になります。
ただし、AWS Lambdaにも環境変数の機能があり、環境変数は保存時に暗号化されます。環境変数の設定と、Secrets Managerのような専用の秘密情報管理サービスは同じものではありません。
どちらを選ぶかは、情報の機密性、権限管理、ローテーションの必要性、運用方法などに応じて判断します。
AWSの具体的な設定や運用については、以下の公式ドキュメントを参考にしてください。
- Amazon AWS Lambdaの環境変数
- Amazon AWS Secrets Managerのベストプラクティス
- Amazon Lambda関数でSecrets Managerのシークレットを利用する
APIキーを安全に管理するためのチェックリスト
Webサイトを新規構築するときや、既存サイトを見直すときは、次の点を確認しておくとよいでしょう。
- APIキーやパスワードをソースコードに直接記述していない
-
.envなどの秘密情報を含むファイルがGitの追跡対象になっていない - 公開用の環境変数に秘密情報を設定していない
- ビルド後のJavaScriptや生成ファイルに秘密情報が含まれていない
-
.envや設定ファイルがWeb公開ディレクトリから取得できない - CI/CDの設定やログに秘密情報が露出していない
- 開発環境と本番環境で認証情報を分けている
- APIキーに必要以上の権限を付与していない
- 漏えい時にキーを無効化・再発行できる手順がある
すでにAPIキーが公開されてしまった場合は、ファイルを削除するだけでは不十分です。
GitHubなどからキーを削除しても、過去のコミットや複製されたリポジトリ、キャッシュなどに残っている可能性があります。まず該当するキーを無効化または再発行し、利用履歴や不審なアクセスを確認したうえで、公開経路を取り除く必要があります。
まとめ
APIキーの漏えいを防ぐためには、秘密情報をソースコードに直接書かないことに加え、開発からビルド、デプロイ、本番運用までの流れを確認することが重要です。
.envを利用していても、フロントエンドのビルド設定によっては秘密情報がJavaScriptへ埋め込まれることがあります。また、GitHubへ誤って登録したキーは、ファイルを削除するだけでは安全な状態に戻せません。
Cloudflare WorkersではSecretsを利用でき、AWSにもSecrets Managerなどの仕組みがあります。利用するサービスに応じた管理方法を選び、秘密情報を必要な場所だけで利用する構成にすることが大切です。
秘密情報は、隠しているつもりかどうかではなく、実際にどこから参照できる状態になっているかで判断する必要があります。 ソースコードだけでなく、生成されたファイルや公開ディレクトリ、デプロイ設定まで確認することが、Webサイトの安全な運用につながります。
