用語辞典
オープンリダイレクトとは — 信頼されたURLを踏み台に、別サイトへ飛ばされる穴
オープンリダイレクトは、あなたのサイトのURLを経由して任意の外部サイトへ転送できてしまう脆弱性です。信頼されたドメインを“踏み台”にしたフィッシングに悪用されます。仕組みの図解と、本命の防御（リダイレクト先を許可リスト化・外部URLを受け取らない）を防御目線で解説します。
「URLの頭は本物のドメインなのに、踏んだら全然違うサイトに飛ばされた」——それがオープンリダイレクトです。仕組みと確実な防ぎ方を解説します（攻撃手順は載せません）。
なぜ危険か
危険の本質は「ドメインへの信頼を悪用される」点です。
| 悪用のされ方 | 何が起きる |
|---|---|
| フィッシングの踏み台 | リンク先頭が本物ドメイン→利用者もフィルタも信用→偽サイトへ誘導 |
| 認証フローの横取り | OAuth等のリダイレクト先を細工し、トークン/コードの受け渡しを狙う |
| 他の脆弱性の増幅 | SSRF や XSS と組み合わせて被害を拡大 |
なぜ成立するか（仕組み）
「ログイン後に元のページへ戻す」などの機能で、戻り先URLをそのまま信じて転送すると起こります。利用者が見るURLの“先頭”は本物のドメインなので、最後まで疑いにくいのが厄介です。
防御：外部URLを受け取らない
遷移先は相対パスだけ許可（最重要）
戻り先は /dashboard のような相対パスのみ受け付け、フルURL（http://・// 始まり）は拒否。利用者が遷移先ドメインを指定できる余地を作らない。
許可リストに照合する
動的な遷移先が要るなら、既知の遷移先の固定セット（マップ）に対してだけ許可。一致しなければ既定ページへ。
文字列判定に頼らない
//evil・バックスラッシュ・@・多重エンコード等の回避が多い。受け取る設計を変える（相対＋許可リスト）方が、フィルタ追記より確実。
どうしても外部へ飛ばすなら明示する
外部遷移が仕様なら、確認ページを挟んで「外部サイトへ移動します」と利用者に見せる。黙って飛ばさない。
当サイトの視点：単体では“低”でも、フィッシングと組むと効く
オープンリダイレクトは単体だと深刻度を低く見られがちですが、本物ドメインの信頼を貸し出してしまうため、フィッシングや認証横取りと組み合わさると一気に効きます。だからこそ「相対パス＋許可リスト」という設計レベルの一手で根を断つのが効率的。SSRF（サーバーを任意先に通信させる）と発想が似ており、どちらも「遷移先・接続先を利用者に決めさせない」が共通の防御原則です。
次に読む
よくある質問
Qオープンリダイレクトの何が問題？
URLの“最初のドメイン”が信頼できる本物（例：ログインページ）なので、利用者もメールフィルタも安心してクリックします。ところがサイトが利用者を任意の外部サイトへ転送してしまうため、本物のドメインを“踏み台”にしたフィッシングや、認証フローでのトークン横取りの起点に悪用されます。
Q一番の防御は？
『遷移先に外部URLを受け取らない』ことです。ログイン後の戻り先などは、フルURLではなく相対パス（/dashboard 等）だけを許可し、許可リスト（既知の遷移先の固定セット）に照合します。どうしても外部に飛ばすなら、確認ページを挟んで利用者に明示します。
Qhttp かどうかチェックすれば十分？
不十分です。// で始まる省略形（//evil.example）やバックスラッシュ、エンコード、@ を使った紛らわしいURLなど回避手法が多数あります。文字列を判定するより、そもそも外部URLを受け取らない設計（相対パス＋許可リスト）が確実です。