HTMLに秘密情報が残るリスク
AIで生成したHTMLやJavaScriptには、動作確認のために書き込んだAPIキーらしき文字列や、外部サービスへの接続情報が残ることがあります。これらは画面に表示されなくても、ソースを開けば読めてしまう場合があります。
秘密情報が含まれたまま公開すると、第三者がそれを悪用できる状態になります。公開前に一度立ち止まって確認することが、こうした流出を防ぐ最初の対策です。
確認すべき情報の種類
確認の対象は、APIキーらしき文字列だけではありません。秘密鍵や認証トークン、外部サービスの接続情報なども、公開すべきでない情報に含まれます。
ここでは具体的なトークンの形そのものを書くことは避けますが、一般に長くランダムに見える英数字の並びや、接続先の認証情報は要注意です。心当たりのある文字列は公開前に取り除く前提で見ていきます。
- APIキーらしき文字列
- 秘密鍵や認証トークン
- 外部サービスへの接続情報や設定値
よくあるNG例と安全な直し方
HTMLにAPIキーが残っていないか確認して取り除く方法では、「検索に出さない」と「見られないようにする」を混同しないことが重要です。noindexやrobots.txtは検索エンジンへの指示であり、アクセス制限そのものではありません。
安全に共有するには、誰に見られると困るかを先に決め、URL共有だけで足りるのか、認証や期限が必要なのかを選びます。共有相手と機密度が決まったら、URLのみ・パスワード・メール認証・会社ドメイン認証のどれで渡すかを選びます。
- NG: 機密情報入りHTMLを認証なしURLで共有し、noindexだけで安心する
- OK: パスワード・メール認証・会社ドメイン認証で閲覧者を絞る
- NG: テスト用APIキーや社内URLをHTML内に残したまま渡す
- OK: 公開前に外部送信先、秘密情報、フォーム送信先を確認する
ギガサイト便の自動スキャンを活かす手順
ギガサイト便は公開前に自動セキュリティスキャンを行い、秘密情報らしき文字列や外部フォームの送信先などを検出して警告します。これを活かすには次の流れが有効です。
警告が出た場合は、公開を止めて元のファイルを直すことが大切です。修正してから再度確認する流れを守ってください。
- トップにHTMLまたはZIPをドラッグアンドドロップします。
- 公開前に表示される自動セキュリティスキャンの結果を確認します。
- 秘密情報らしき文字列の警告が出たら、元のファイルから該当箇所を取り除きます。
- 修正したファイルを再度アップロードし、警告が解消されたことを確認します。
- 問題がないことを確認してから認証方式と公開期限を設定して公開します。
自動スキャンに頼りきらず手動でも確認する
自動スキャンは強力ですが、すべてのケースを完全に検出できるとは限りません。最終的には人の目でも確認することで、見落としを減らせます。
手元のエディタでファイルを開き、APIキーらしき文字列や認証情報が含まれていないかを検索しておくと安心です。怪しい文字列が見つかった場合は、公開用のファイルからは削除し、本来の秘密情報はサーバー側など安全な場所で管理する方針に切り替えてください。
公開前チェックを習慣にする
APIキーらしき文字列の混入は、急いで公開しようとするときほど起こりがちです。公開前に必ずスキャン結果を確認し、警告があれば対処してから進めるという流れを習慣にしましょう。
そもそも秘密情報を公開用のファイルに含めない設計にしておくことが根本的な対策です。スキャンと手動チェックは、その上での最後の安全網として位置づけると効果的です。
疑わしい文字列を見つけたときの判断順
HTML内に長い英数字やtoken、secret、keyのような名前を見つけても、それが本当に秘密情報かどうかすぐに判断できないことがあります。迷ったときは「公開してよい値か」ではなく「漏れて困る値の可能性があるか」から考えます。
判断に迷う値は、いったん公開HTMLから取り除き、必要ならサーバー側や環境変数で扱う前提に戻します。AIが作ったサンプル値に見えても、過去のプロンプトや貼り付けたコードから本物が混ざることがあるため、楽観的に公開しないことが大切です。
- 値の名前にkey、token、secret、password、bearerが含まれていないか見る
- 外部APIのURLや決済・フォーム送信先と一緒に置かれていないか確認する
- 本物か判断できない値は公開前に削除または差し替える
- 一度でも公開した可能性があるキーは、サービス側でローテーションする
見つけたら削除だけで終わらせない
公開前にキーらしき値を見つけたら、HTMLから削除するだけでは不十分な場合があります。一度でも共有・プレビュー・チャット添付に使ったファイルに本物のキーが入っていた可能性があるなら、発行元サービス側で無効化またはローテーションしてください。
特にAIに過去のコードを貼り付けてHTML化した場合、環境変数名やダミー値に見えて実は本物、という混入が起きます。疑わしい値は「本物だったら困る」前提で扱うほうが安全です。
- 公開用ファイルから値を削除する
- 発行元サービスでキーをローテーションする
- 古いURLや添付ファイルが残っていないか確認する
- 再アップロード後にスキャンと手動検索をもう一度行う
よくある質問
自動スキャンで何が検出されますか。
ギガサイト便の自動セキュリティスキャンは、秘密情報らしき文字列や外部フォームの送信先などを検出して警告します。公開前に結果を確認することで、APIキーらしき文字列の混入に気づきやすくなります。
警告が出たらどうすればよいですか。
元のファイルから該当する文字列を取り除き、修正版を再度アップロードしてください。本来必要な秘密情報は公開用ファイルに含めず、サーバー側など安全な場所で管理する方針に切り替えるとよいでしょう。
自動スキャンだけに任せても大丈夫ですか。
自動スキャンは有効ですが、すべてのケースを完全に検出できるとは限りません。手元のエディタでも怪しい文字列を検索するなど、人の目による確認を併用すると見落としを減らせます。
そもそもキーを含めないようにするには。
公開用のファイルには秘密情報を直接書かない設計が基本です。動作確認で埋め込んだ情報は公開前に必ず削除し、認証が必要な処理はサーバー側で扱うようにすると、混入そのものを防ぎやすくなります。
noindexを設定すれば認証は不要ですか？
不要ではありません。noindexは検索結果への表示を抑えるための指定で、URLを知っている人の閲覧を止める仕組みではありません。閲覧者を制限したい場合は認証が必要です。
キーかどうか分からない長い文字列は、どう扱うべきですか？
公開して問題ないと確認できるまでは、秘密情報の可能性があるものとして扱います。HTMLから削除し、必要な値ならサーバー側の環境変数や安全な設定に移し、すでに外へ出した可能性がある場合は発行元サービスで無効化・再発行を検討してください。