なぜ危ないのか
OAuth callbackの実装を含むHTMLを社外に送ると、受け取ったエンジニアが開発者ツールでソースを精査し、client_idやcallback URLの構造を把握できる。その情報を使って同様のOAuthフローを模倣するページを作られると、自社サービスのユーザーが偽ページに誘導されるフィッシングの基礎情報が揃ってしまう。
社外レビュアーが善意の担当者であっても、そのPCやクラウドストレージにHTMLが保存されることでデータの保管場所が増える。HTMLにOAuth認証情報が含まれていると、PCの紛失や不正アクセスによってcredentialが流出する経路が増えることになる。
レビューのためだけに公開したURLが、レビュー後も有効なまま放置されるケースが多い。OAuthフローを含むHTMLが長期間公開されていると、URLをスキャンした第三者がcallback URLのパターンを記録し、将来の攻撃の準備に使うことがある。期限管理の重要性は通常のHTMLより高い。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
まず`client_secret`の有無を確認する。`grep -i 'client_secret' review.html`でヒットした場合は、その値が空文字やプレースホルダーかを確認する。実際のシークレット文字列（英数字で30文字以上の場合が多い）が含まれていれば、共有前に必ず削除または置き換えが必要だ。
callback URLとして登録済みのURLが使われているかを確認する。OAuth Providerのコンソールにログインし、該当アプリの「Authorized redirect URIs」または「Callback URLs」に登録されているURLと、HTML内のredirect_uriが一致するかを比較する。一致しない場合はOAuthフローが動かないが、攻撃者に情報が渡るリスクは存在する。
トークンの保存先も確認対象だ。`localStorage.setItem`や`sessionStorage.setItem`でaccess_tokenやrefresh_tokenを保存している場合、XSSと組み合わせるとトークンが盗まれるリスクがある。レビュー用HTMLではトークンをlocalStorageに保存せず、ログとして表示するだけにするか、完全に削除する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
client_secretを削除してclient_idをプレースホルダーに置き換えた状態のHTMLを共有することが最低条件だ。それに加えて、callback URLの動作を確認するためのテスト用アプリを用意し、そのcallback URLをレビュアーのドメインまたはテスト用URLに限定する設定をOAuth Providerコンソールで行う。
ギガサイト便のメール認証機能を使えば、レビュアーの会社メールアドレスを事前に登録し、そのメールアドレスでアクセスした人だけが見られるURLを発行できる。社外レビュアーが5名以下であれば全員分のメールアドレスを登録することで、URLが転送されても不特定多数のアクセスを防げる。
共有メールまたはSlackメッセージに、「このURLのHTMLにはOAuthのcallback処理が含まれます。開発者ツールでソースを確認しても構いませんが、このHTMLを第三者に共有しないでください」という一文を添える。レビュアーへの情報提供として有効で、不注意な転送を防ぐ抑止力にもなる。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
OAuth実装を含むHTMLのための社外共有手順を、通常のHTMLとは別のドキュメントとして作成する。手順書には「client_secretの有無確認→プレースホルダー置換→テスト用アプリ作成→認証付きURL発行→共有期限設定→共有後のアプリ削除」というステップを順番に記載する。
AIにOAuth UIを生成させる際のプロンプトテンプレートに「client_secretはHTMLに含めず`YOUR_CLIENT_SECRET`とプレースホルダーで記述すること。callback URLは`https://localhost:3000/callback`を使うこと」という指示を定型として追加する。この指示があるとAIが安全なデフォルト値を選ぶ確率が上がる。
月次でOAuth Providerのコンソールを確認し、新規に追加されたアプリ・更新されたredirect_uri設定がないかをレビューする。AIを使ったHTMLプロトタイプの増加に伴いOAuthアプリが増えやすい環境では、この棚卸しによって不要なアクセス経路を定期的に閉じられる。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
OAuth callbackを含むHTMLのチェックは、開発者本人と別の担当者が行うべきですか？
理想は別担当者によるレビューだが、少なくとも生成直後でなく翌日以降に自分で確認し直すことで見落としが減る。チェックリストを使えば一人でも一定品質を保てる。高リスクな共有（金融・医療）では二人確認を推奨する。
GitHubのパブリックリポジトリにOAuth callbackを含むHTMLをコミットしてしまった場合、どうすればよいですか？
まずOAuth Providerコンソールでそのアプリのclient_secretをローテーション（再生成）する。次にgit filter-repoまたはGitHub Supportに依頼してコミット履歴から該当ファイルを除去する。公開期間中にclient_secretが使用されていないかProviderのログで確認することも重要だ。
レビュー後にOAuthアプリを削除する代わりに、redirect_uriを空にする方法では不十分ですか？
redirect_uriを空にするとOAuthフローがエラーになるため悪用リスクは下がるが、アプリのclient_idは残るため攻撃者が試みるフィッシングの情報源になりうる。完全に使い終わったアプリは削除することを推奨する。