サイトにAPIキーが露出したら、削除だけで十分？

変数名では権限は分からない

AIで作ったページがブラウザーからメールサービスを呼び、JavaScriptにAPI_KEYという値があるとします。名前だけでは脆弱性とは判断できません。提供元の資料で、公開識別子、制限付きクライアントキー、操作を許可する秘密のどれか確認します。他人のサイトの認証情報を試してはいけません。これは仮例で、顧客の事故報告ではありません。

自社サービスなら、アカウント所有者に管理画面で種類と権限を確認してもらいます。対象スクリプトのURLと発見時刻を記録し、値全体をメール、チケット、AIチャットに貼らないでください。共有画像でも秘密を隠します。

コピーの整理より先に古い認証を止める

秘密の露出が確認されたら、所有者と速やかに失効または更新を手配します。GitHubの指針もリポジトリ履歴の整理より先にこれを求めています。再ビルドで配布経路は減っても、以前ダウンロードされた値は使われ得ます。

新しい秘密を置く場所も見直します。秘密を使う処理はサーバー側で行い、適切な秘密情報ストアへ保存します。ビルドが再びブラウザー資産へ埋め込まないか確認してください。環境変数でも公開コードに含まれ得ます。移行中に安全に動かせない機能は、一時停止を合意する方が、再度露出するキーを発行するより適切です。

請求が増えていなくても調査は終わらない

露出した可能性のある期間について、利用できる利用記録と監査ログを確認します。キーで可能だった操作と、記録で分かる事実を分けます。請求が平常でもデータへのアクセスがなかった証明にはならず、ログ不足は検証上の制限です。不正利用が疑われる証拠は所有者の事故対応へ引き継ぎます。

配布スクリプト、CDNキャッシュ、リポジトリ、ビルド成果物、共有した調査資料など、管理下のコピーを洗い出します。履歴整理は共同作業者と調整してください。書き換えは他者に影響し、他者のクローンまでは消せません。記録はアクセスを制限し秘密を伏せます。

変更後の確認

自身の許可済みアカウントで旧認証の失効と、新しい認証の最小権限を確認します。本番のブラウザー資産に秘密がなく、通常機能が動くことを確認し、配備IDと時刻を残します。影響の実証のために第三者費用を発生させないでください。

外部チェックで見える認証情報を発見できる場合はありますが、提供元ログの調査、更新、ソースレビュー、事故対応は別作業です。Mingxi標準チェックには含まれず、露出キーが一度も使われなかったと証明するものでもありません。未確認部分を引き継ぎに残します。

実行チェックリスト

• 提供元と所有者にキーの種類を確認する。
• 露出した秘密を速やかに失効または更新する。
• 利用可能なログを調べ、証拠の秘密を隠す。
• 新しい配備と通常機能を確認する。

よくある質問

JavaScript内のキーはすべて消すべきですか？

いいえ。公開を前提とするクライアントキーもあります。提供元の権限と制限の要件に従ってください。公開識別子とサーバーの秘密は同じ扱いにはできません。