短.beオープンリダイレクト (Open Redirect) とは、Web アプリケーションが外部から渡された URL パラメーターの値を検証せずにリダイレクト先として使用してしまう脆弱性です。OWASP (Open Web Application Security Project) の Top 10 では、2025 年版で第 1 位となったアクセス制御の不備 (A01) に含まれる CWE-601 (信頼できないサイトへの URL リダイレクト) として整理されています。
具体例を示します。「https://trusted-site.com/redirect?url=https://evil-site.com」のような URL で、trusted-site.com が url パラメーターの値を検証せずにリダイレクトすると、ユーザーは信頼できるドメインのリンクをクリックしたつもりで悪意のあるサイトに誘導されます。
オープンリダイレクトがフィッシング攻撃に悪用される理由は、信頼できるドメインの URL がリンクの入り口になるためです。メールのセキュリティフィルターやユーザー自身の目視チェックでは、リンクの先頭が正規のドメインであれば安全と判断しがちです。
短縮 URL サービスは本質的にリダイレクトサービスであるため、オープンリダイレクトの問題と密接に関わります。悪意のあるユーザーが短縮 URL サービスを使ってフィッシングサイトへのリンクを作成するケースは実際に発生しています。短縮 URL サービス側にも対策はありますが、どのような手段でどこまで検出しているかは公開されないのが一般的です。利用者から見える形の対策としては、リダイレクト前にリンク先を表示する警告画面 (スプラッシュページ) や、不正利用の報告窓口などがあります。ただしこうした機能があること自体は、そのサービスで発行されたリンクが安全であることを意味しません。リンクを受け取った側は、検出の仕組みを前提に安全性を判断するのではなく、外から確認できる範囲で見分けるほうが確実です。
開発者がオープンリダイレクトを防ぐには、リダイレクト先をホワイトリストで制限する、相対 URL のみ許可する、リダイレクト先のドメインを検証するなどの対策が有効です。URL パラメーターをそのままリダイレクト先に使う実装は、どのような場合でも避けるべきです。
検証を実装したつもりで抜け穴が残る典型が 2 つあります。1 つはドメインを前方一致で照合する実装です。「https://trusted-site.com.attacker-domain.example/」のようにホスト名を後ろへ伸ばした URL は前方一致を通過してしまうため、URL を解析してホスト名を取り出し、許可リストとの完全一致で判定します。もう 1 つは「/」で始まる値をすべて相対 URL とみなす実装です。「//attacker-domain.example/」はスキーム相対 URL として解釈され、ブラウザーは別のドメインへ移動します。先頭が「//」の値は外部 URL として扱う必要があります。