目次
ログインが終わったら元のページへ戻す。よくある機能ですが、戻り先を外部から自由に指定できると、自分のサイトを経由して別のサイトへ誘導する入口になる場合があります。利用者が最初に見たドメインが正しいことと、最後の宛先が正しいことは別です。
本記事は2026年10月18日にOWASPの一次資料を確認した実務解説です。特定サイトの新しい被害の速報ではありません。会員画面とリンク中継の構成は仮想例で、設計の判断と試験項目は本サイトの提案です。画面遷移を実装する既存のJavaScript記事とは分け、遷移先を信頼する境界を扱います。
スポンサーリンク
リダイレクトが使う信頼を理解する
オープンリダイレクトは、外部入力の宛先を十分に検証せず利用者を転送できる問題です。自社のURLを入口にできると、案内やメールを受け取った人が、その先も自社のページだと誤解するおそれがあります。
OWASPは、検証されないリダイレクトと内部の転送のリスクを説明しています。重要なのは、単に外部へ出ることの有無ではなく、誰が宛先を選べて、その宛先へどの状態や情報を引き継ぐかです。
正規の外部サイトへリンクする機能そのものを禁止する必要はありません。目的が明確な外部リンクと、認証後に自動で移動する戻り先では、利用者の期待と機能が異なります。用途ごとに許可する範囲を決めます。
出典：OWASP Unvalidated Redirects and Forwards Cheat Sheet。
任意のURLより業務上の行き先を受け取る
戻り先が「注文一覧」「プロフィール」「問い合わせ履歴」のように限られるなら、URLそのものを受け取る必要があるかを考えます。既知のキーから、サーバー内で固定した宛先へ対応付ける方法なら、外部入力にURL構文の自由度を渡さずに済みます。
本サイトは、ログイン前に許可された行き先を確認し、認証後もその行き先へアクセスする権限を別に検証する方法を勧めます。宛先のキーが正しいからといって、他人の注文を表示してよいわけではありません。
未知のキーや失効した状態は、安全な既定の画面へ戻します。エラーを直すために入力された値を無条件で採用する処理を入れないようにします。利用者が迷わない案内と、許可する宛先の固定を両立させます。
スポンサーリンク
URLを使うなら解析してから条件を確認する
外部サービスとの連携などでURLを受け取る必要がある場合は、言語の標準的なURLパーサーを使い、スキーム、ホスト、ポートなどの構成要素を確認します。許可するドメインらしい文字列が含まれるかだけで判断しないでください。
文字列の前方一致や末尾一致は、URLの解釈と同じではありません。見た目が似た文字、ユーザー情報の部分、区切り、エンコードの扱いなどで、想定と解析結果が異なる場合があります。独自の短い正規表現であらゆるURLを理解しようとするより、受け付ける形を小さくします。
複数回のデコードや正規化を経てから実際の転送先が変わらないかも確認します。検証した値と、最終的にLocationヘッダーやブラウザーの遷移へ渡す値を対応させることが重要です。
相対URLも無条件に安全とは限らない
同じサイト内の移動だけなら、相対的なパスを使う設計が候補になります。ただし、スラッシュから始まれば何でも内部のパスだと扱う単純な条件は避けます。URLの解釈によってホストを指定する形などを含まないかを、標準パーサーと実際の処理で確認します。
許可したパスでも、内部に別の転送機能があれば、もう一段先で外部へ出る可能性があります。戻り先だけを点検せず、中継するURLとその引数の扱いを調べます。リダイレクトの連鎖を、最初の一回が自社だから安全と判断しないようにします。
可能なら、業務で必要なパスの範囲を固定します。任意のパスを受け付けるより、画面の役割に合う許可リストへ狭める方が、後で新しい転送機能が増えたときにも影響を把握しやすくなります。
スポンサーリンク
認証情報や秘密を宛先へ持ち回らない
遷移先を作るとき、元のクエリ文字列を丸ごと引き継ぐ設計を見直します。認証コード、再設定用の秘密、内部の識別情報などが混ざっていれば、不要な宛先へ渡す経路になるおそれがあります。
本サイトは、引き継ぐ情報を用途ごとに選び、秘密の状態はサーバー側で管理する方法を検討することを勧めます。URLへ長い状態を入れる場合も、誰が作り、何に結び付け、いつ失効させるかを決めます。単に文字列を署名すれば、許可していない宛先でもよいという意味にはなりません。
ログや解析サービスへ戻り先の全文を送る必要があるかも確認します。調査には、宛先の分類や安全な内部キーを使い、秘密を含む可能性があるURLを無差別に保存しないようにします。
OAuthなどのコールバックとは要件を分ける
通常の画面の戻り先と、OAuthなどの認証プロトコルのコールバックは同じ機能ではありません。認証連携には提供元の公式仕様に沿った登録と検証が必要です。汎用の戻り先パラメーターを、そのまま認証の宛先へ使い回さないようにします。
正規のコールバックを受け取った後、さらに戻り先へ移動する場合も、その先の検証が残ります。認証処理が成功したことは、アプリの別のパラメーターで指定した宛先を信頼してよい理由にはなりません。
アプリの内部転送では、元の入口で認可したことを理由に、転送先の権限確認を省略しないことが重要です。表示の都合で別の処理へ渡しても、その機能が要求する対象と権限を確認します。
正規の戻り先と拒否する宛先を対にする
仮想の会員サイトなら、許可された注文一覧へ戻れることを最初に確認します。次に未知のキー、許可していない外部ホスト、不正な形式、二段階の転送を検証環境で試します。実際の利用者へ偽のリンクを送って確認する必要はありません。
応答のLocationと、ブラウザーが最終的に開く場所を照合します。サーバー側で拒否しても、フロントエンドが同じ入力を読み直して別の場所へ移動していないかを確認します。表示した警告と実際の移動先が一致することが重要です。
入力が無効だった場合は、既定の画面へ安全に戻り、正規の業務を続けられることも確かめます。異常な値で無限の転送や再ログインが発生しないようにします。
| 宛先の種類 | 推奨する設計 | 確認する動作 |
|---|---|---|
| 決まった内部画面 | 既知のキーから固定先へ変換 | 未知のキーは安全な既定値へ |
| 外部の提携先 | 必要なオリジンなどを明示 | 似た文字列だけでは許可しない |
| 相対パス | 解釈と許可範囲を限定 | 外部ホストの指定へ化けない |
| 内部の転送処理 | 転送先でも認可を確認 | 入口の認証だけで通さない |
利用者への確認画面だけに任せない
外部サイトへ移動する案内は、利用者が行き先を理解する助けになります。ただし、無条件の転送機能に確認画面を一枚足しただけで、サーバー側の検証を省略しないでください。正規の業務で必要な転送なのかという判断は残ります。
案内に表示するURL自体も、安全な表示処理を通します。入力をそのままHTMLへ埋め込むと、リダイレクトとは別の問題を増やすおそれがあります。表示する情報を必要な範囲に整理し、機微なクエリを見せないことも検討します。
外部中継サービスを継続するなら、悪用の連絡先、停止する条件、不要な宛先を削除する手順を用意します。自社の名前を入口として使わせる機能だという認識を共有してください。
スポンサーリンク
戻り先の保存と実行の間にある変更を考える
仮想のサービスで、ログイン前に戻り先を検証し、ログイン後に要求パラメーターを読み直して移動するとします。検証した値と使用する値が違えば、最初の検証は最終の宛先を守れません。許可した行き先を内部の状態へ結び付け、最終的に使う値まで追うことが必要です。
ログイン中に同じブラウザーで複数の画面を開く場合も試します。別の画面の戻り先で上書きされ、重要な業務が想定外の場所へ移動しないかを確認します。状態には用途と有効期間を設け、古いリンクの再利用時は安全な既定の画面へ戻すなど、利用者が理解できる扱いを用意します。
認証の失敗、キャンセル、期限切れでも同じ基準を維持します。成功したときだけ厳密に検証し、失敗したときのエラー案内は任意のURLへ飛ばせる、といった例外を残さないでください。
転送先の変更は外部への信頼の変更として扱う
提携先のドメインが変わった場合、許可リストを追加する担当者は新しい宛先が正規かを確認します。届いたメールの文面だけで登録せず、既知の窓口や契約情報で照合する手順を設けます。
旧ドメインをしばらく残す必要がある場合は、理由と期限を記録します。解約したサービスや管理を失った名前を、便利だからと許可し続けないことが重要です。外部へ移動する機能も、ドメインのライフサイクルと一緒に管理してください。
スポンサーリンク
画面遷移の変更を安全性のレビューへ含める
新しいキャンペーン、ログイン方法、フロントエンドのルーターを導入するときは、戻り先を組み立てる箇所を確認します。古いURL形式を残す場合、その処理にも同じ許可条件が適用されるかを見ます。
運用の到達点は、URL検証のための複雑な文字列処理を増やすことではありません。用途に必要な行き先だけを選べるようにし、解析した宛先と実際の遷移先が一致し、権限と秘密が別に守られる状態を作ることです。
許可リスト、既定の画面、失効の条件、試験したパターンを小さな仕様として残すと、画面が増えたときにも同じ判断を再利用できます。
参考資料
以下は2026年10月18日に直接確認した一次資料です。製品やサービスの設定は、実際に利用する版と環境に対応する資料で確認してください。
