Next.jsのオープンリダイレクト対策 — 認証 callbackUrl / redirect() を検証する

最初に結論を述べます。オープンリダイレクトは、redirect() や callbackUrl にユーザー入力をそのまま渡したときに空く穴で、対策の本質は「遷移先を文字列として信じない」ことに尽きます。 安全側の既定は「自オリジンの相対パスだけを許可する」。外部に飛ばす正当な理由がある経路だけ、ホストの完全一致allowlistとスキーム固定で例外的に許す——この2段構えで、機械的に潰せます。

これは難しい攻撃ではありません。URLのクエリに ?next=https://evil.example と書くだけ。にもかかわらず本番に残りやすいのは、自分のアカウントで触っている限り絶対に顕在化しないからです。開発者もAIも「ログイン後に元のページへ戻る」というハッピーパスは作りますが、「戻り先に攻撃者URLを差し込まれたら」はデモでは誰も試しません。本記事は、その見落としがどこに空き、なぜ素朴なチェックでは塞げず、どう検証すれば安全側に倒せるのかを、Next.jsの認証フローの実コード（脆弱→修正）で解説します。OWASPはこれを古くから「Unvalidated Redirects and Forwards」として整理しており、現在も OWASP Web Security Testing Guide の検査項目、OWASP ASVS の検証要件、そして OWASP Top 10 が説く入力検証の規律の中に位置づけられています。

1. オープンリダイレクトとは——信頼ドメインを「踏み台」にする転送

オープンリダイレクトは、アプリが利用者の操作できる値を遷移先として受け取り、検証せずにそこへ転送してしまう欠陥です。攻撃の起点になるリンクは、こういう形をしています。

https://yourapp.com/login?next=https://evil.example/login
        ^^^^^^^^^^^^                ^^^^^^^^^^^^^^^^^^^^^^^^
        信頼される自社ドメイン        実際の着地先（攻撃者）

ユーザーがメールやSNSで見るのは yourapp.com という正規のドメインです。ホバーしてもドメインは自社。メールのスパムフィルタも、URL検査も、自社ドメイン宛なので通します。ところがアクセスすると、アプリは next パラメータを信じて https://evil.example/login へ転送する。ドメインの信頼が、丸ごと攻撃者に貸し出される——これがオープンリダイレクトの本質です。

重要なのは、このリクエストがHTTPとして完全に正常だという点です。不正な文字列もインジェクションも含まない。next の値が「外部ホストである」という事実だけが問題で、それが攻撃かどうかは「このアプリがどの遷移先を許すか」というアプリ固有のルールでしか決まりません。だからWAFやセキュリティヘッダーでは構造的に止められず、コード側の検証が要ります。この「汚染入力→危険シンク」という構造は注入クラス全体に共通で、全体像はNext.js × Supabase アプリケーションセキュリティ完全ガイドに地図を描いています。

2. なぜ危険か——フィッシングと、認証直後のトークン窃取

オープンリダイレクト単体で「サーバーが乗っ取られる」ことはありません。怖いのは、これが**他の攻撃を成立させる『信頼の踏み台』**になることです。被害は大きく2系統あります。

2-1. フィッシング——ドメインの信頼を貸し出す

攻撃者は https://yourapp.com/login?next=https://evil.example/login を配布します。ユーザーは自社ドメインを信じてクリックし、一瞬で見分けのつかない偽ログイン画面（evil.example）に着地します。そこで入力した認証情報やワンタイムコードがそのまま盗まれる。最初の一歩が正規ドメインであることが、フィルタもユーザーの警戒も突破します。

2-2. 認証直後のトークン窃取——OAuth/コールバックの戻り先

より深刻なのは、認証フローに絡む場合です。OAuth/OIDCでは、認可サーバーが発行する認可コードやトークンは、登録済みの戻り先（redirect_uri）に届けられます。通常はredirect_uriの厳密登録で任意ホストへの送信を防ぎますが、許可リストに載った自社ホスト上にオープンリダイレクトがあると連鎖されます。

認可サーバー → https://yourapp.com/callback?next=https://evil.example
            （登録済みの自社ホストなので通る）
yourapp.com/callback → next を信じて evil.example へ転送
            → 認可コード／トークンがクエリ・フラグメント・Referer 経由で流出

アプリ独自の callbackUrl（ログイン後にユーザーを元の画面へ戻すための値）でも事情は同じです。ユーザーが**最も警戒を解く「認証に成功した直後」**に攻撃者サイトへ送られるため、二段階の偽装やセッションの引き継ぎに悪用されます。OWASP ASVS が「許可されたURLにのみリダイレクトする（allowlist）か、信頼できない遷移先では警告を出す」ことを検証要件として求めているのは、まさにこの連鎖を断つためです。

3. Next.jsでオープンリダイレクトが空く4つの場所

Next.jsでは、遷移先を扱うAPIがいくつもあります。next/navigation の redirect()、Route Handlerの NextResponse.redirect()、middlewareの NextResponse.redirect()、そしてクライアントの router.push() / window.location。そのどれもが、利用者の入力を素通しにすると穴になります。 典型を脆弱コードで4つ挙げます。

3-1. Server Componentでの redirect(searchParams.next)

next/navigation の redirect() は、絶対URLを渡せば外部にも飛びます。Next.jsはこれを制限しません。安全性の責任は完全に呼び出し側にあります。

// app/login/page.tsx — 脆弱：next をそのまま redirect に渡す
import { redirect } from "next/navigation";

export default async function LoginPage({
  searchParams,
}: {
  searchParams: Promise<{ next?: string }>;
}) {
  const { next } = await searchParams; // ← クライアントが自由に変えられる汚染入力
  const session = await getSession();
  if (session) {
    redirect(next ?? "/dashboard"); // next="https://evil.example" でも素直に飛ぶ
  }
  // …ログインフォームを表示
}

3-2. ログインServer Actionの callbackUrl

"use server" のアクションは実質POSTエンドポイントで、formData の値は等しくクライアント操作可能です。「画面に出していない隠しフィールドだから安全」は成立しません。

// app/login/actions.ts — 脆弱：callbackUrl を検証せず認証直後に飛ばす
"use server";
import { redirect } from "next/navigation";

export async function login(formData: FormData) {
  const callbackUrl = String(formData.get("callbackUrl") ?? "/dashboard");
  await signIn(formData); // 認証成功
  redirect(callbackUrl); // ← 最も信頼された瞬間に攻撃者サイトへ送られうる
}

3-3. OAuth/認証コールバックのRoute Handler

SupabaseやAuth.jsの戻りを受ける app/auth/callback/route.ts は、next を受け取ってセッション確立後に転送する定番です。ここが一番踏まれます。

// app/auth/callback/route.ts — 脆弱：戻り先を new URL に素通し
import { NextResponse, type NextRequest } from "next/server";

export async function GET(req: NextRequest) {
  const next = req.nextUrl.searchParams.get("next") ?? "/";
  await exchangeCodeForSession(req); // セッション確立
  return NextResponse.redirect(new URL(next, req.nextUrl.origin));
  // next="//evil.example" → new URL は https://evil.example に解決される
}

NextResponse.redirect() は絶対URLを要求するため new URL(next, origin) で組み立てがちですが、new URL は第1引数が絶対URLやプロトコル相対だと第2引数の基準を上書きします。これが次節のバイパスの温床です。

3-4. middlewareの NextResponse.redirect()

未認証を弾いて「戻り先付き」でログインへ送る、その戻り先 (from) を再利用するときに同じ穴が空きます。

// middleware.ts — 脆弱：戻り先 from を検証せず redirect
import { NextResponse, type NextRequest } from "next/server";

export function middleware(req: NextRequest) {
  const from = req.nextUrl.searchParams.get("from");
  if (from) return NextResponse.redirect(new URL(from, req.url)); // 検証なし
  // …
}

なお、middlewareの NextResponse.rewrite() に利用者制御のURLを渡すのはオープンリダイレクトではなくSSRF（自社エッジが内部資源へ到達する）に化けます。こちらは別クラスの問題で、Next.jsのSSRF対策で扱っています。

4. なぜ単純なチェックは破られるのか——バイパスの体系

「http で始まっていなければ相対パスだろう」「自社ドメインを含んでいればOK」——こうした文字列ベースの素朴なチェックは、ことごとく回避されます。代表的なバイパスを整理します（攻撃者ドメインは evil.example、自社は yourapp.com とします）。

罠の核心は2つです。

ひとつは // と \。//evil.example はスキームを省いた「プロトコル相対URL」で、ブラウザは現在のスキームを補って https://evil.example として扱います。startsWith("/") のチェックは通過してしまう。さらに厄介なのが円記号 (\) です。WHATWGのURL標準では、http/httpsのような特別なスキームにおいて \ は / と同じに正規化されるため、/\evil.example は //evil.example と等価になり、startsWith("//") という対策をすり抜けます。

もうひとつは @（userinfo）とサブドメイン詐称。https://yourapp.com@evil.example は、@ の前がユーザー情報、ホストは evil.example です。文字列に自社ドメインが「含まれているか」を見るチェックは全滅します。host を完全一致で見ない限り、yourapp.com.evil.example や evil.example/yourapp.com も通ってしまいます。

結論はこうです。遷移先は「文字列」ではなく「構造（origin/host/scheme）」で判断しなければならない。 そしてその構造を、ブラウザと同じルールで解釈できる道具が new URL です。

5. 正しい対策——相対パス強制・new URL検証・host allowlist

5-1. 既定は「自オリジンの相対パスだけ」を許可する

ほとんどのログイン後遷移は、自分のアプリ内のパスに戻るだけです。ならば「自オリジンの相対パス以外は全部捨てる」のが最も堅く、最も単純です。鍵は、ブラウザと同じパーサ（new URL）で解決し、オリジンが一致するかだけを見ること。文字列の前方一致は一切使いません。

// lib/safe-redirect.ts — 自オリジン上の相対パスだけを許可する（既定の防御）
export function toSafeRelativePath(
  input: string | null | undefined,
  fallback = "/dashboard",
): string {
  if (!input) return fallback;

  // 実在しない予約TLDを基準オリジンにする。許可ホストと偶然一致しないため安全。
  const base = "https://placeholder.invalid";
  let url: URL;
  try {
    url = new URL(input, base); // ブラウザと同じ規則で解決（\→/ 正規化等もここで吸収）
  } catch {
    return fallback; // パース不能な値は捨てる
  }

  // 別ホストに化けたら拒否。これ1つで //evil・/\evil・@evil・絶対URL を全部弾く。
  if (url.origin !== base) return fallback;

  // 万一に備え、絶対URLは絶対に返さない。パス成分だけに削る。
  return url.pathname + url.search + url.hash;
}

なぜこれで前節のバイパスが全滅するのかを確かめます。

• //evil.example → 解決すると origin が https://evil.example になり、base と不一致 → 拒否。
• /\evil.example → \ が / に正規化され //evil.example と等価 → origin 不一致 → 拒否。
• https://yourapp.com@evil.example → host が evil.example → origin 不一致 → 拒否。
• /dashboard?tab=1 → origin が base と一致 → "/dashboard?tab=1" を返す（正規）。

「許可ホストの判定」を自前の文字列処理で書かず、URLパーサに委ねるのがこの設計の肝です。さらに最後に pathname + search + hash だけを返すことで、たとえ将来オリジン判定をすり抜ける入力が現れても、絶対URLが出力に混じる経路自体を断っています（多層防御）。

5-2. 外部に飛ばす正当な理由があるなら、host完全一致のallowlist

決済プロバイダや系列ドメインへ戻すなど、本当に外部へリダイレクトする要件もあります。その場合だけ、明示的なallowlistで例外を許します。ここでも判定は構造に対して行い、host は完全一致、スキームは https に固定します。

// lib/safe-redirect.ts — 外部遷移は明示的 allowlist でのみ許可する
const ALLOWED_HOSTS = new Set([
  "app.example-corp.com",
  "docs.example-corp.com",
]);

export function toAllowlistedUrl(
  input: string | null | undefined,
  fallback = "/",
): string {
  if (!input) return fallback;

  let url: URL;
  try {
    url = new URL(input); // 絶対URL必須。相対は throw → fallback
  } catch {
    return fallback;
  }

  if (url.protocol !== "https:") return fallback; // スキームを固定（javascript: 等を排除）
  if (!ALLOWED_HOSTS.has(url.hostname.toLowerCase())) return fallback; // host を完全一致で照合
  return url.toString();
}

url.hostname を小文字化して Set と完全一致させるのが要点です。endsWith(".example-corp.com") のような末尾一致は evilexample-corp.com を通すため使いません。サブドメインまで許すなら、hostname === "example-corp.com" || hostname.endsWith(".example-corp.com") のように先頭のドットでアンカーします。

5-3. Next.jsの各経路に適用する

検証関数を用意したら、3節の脆弱コードは「検証してから飛ばす」だけで塞がります。

// app/auth/callback/route.ts — 修正：検証してから redirect
import { NextResponse, type NextRequest } from "next/server";
import { toSafeRelativePath } from "@/lib/safe-redirect";

export async function GET(req: NextRequest) {
  const next = toSafeRelativePath(req.nextUrl.searchParams.get("next"));
  await exchangeCodeForSession(req);
  // next は同一オリジンの相対パスであることが保証されているので new URL も安全
  return NextResponse.redirect(new URL(next, req.nextUrl.origin));
}

// app/login/actions.ts — 修正：callbackUrl を相対パスに正規化してから redirect
"use server";
import { redirect } from "next/navigation";
import { toSafeRelativePath } from "@/lib/safe-redirect";

export async function login(formData: FormData) {
  const callbackUrl = toSafeRelativePath(formData.get("callbackUrl")?.toString());
  await signIn(formData);
  redirect(callbackUrl); // 自オリジンのパスにしか飛ばない
}

Server Component や middleware も同様に、searchParams から取り出した直後に toSafeRelativePath() を通すだけです。検証は「入力を受け取った場所」で1回、遷移の直前に行う——これが規律です。

エンコードの扱いに注意。 searchParams.get() や formData.get() はすでにパーセントデコード済みの値を返します。だから %2f%2fevil（=//evil）はこの時点で復号されており、上の検証で正しく弾けます。逆に、デコード前の生文字列を別の場所で再利用すると二重デコードでズレるため、「パース済みのAPIから取り出した値」を検証し、それをそのまま使うのが安全です。

5-4. バイパス入力を回帰テストに固定する

検証関数は「一度書いて終わり」にしてはいけません。前節のバイパス入力をそのままテストに固定しておけば、誰か（人間でもAIでも）が「相対パスだけだから」と検証を緩めた瞬間に、CIが赤くなって退行を止めます。new URL ベースの検証は副作用のない純粋関数なので、vitestで安く・速くテストできます。

// lib/safe-redirect.test.ts — バイパス入力が確実に弾かれることを固定する
import { describe, expect, it } from "vitest";
import { toSafeRelativePath } from "./safe-redirect";

describe("toSafeRelativePath", () => {
  it("自オリジンの相対パスは通す", () => {
    expect(toSafeRelativePath("/dashboard?tab=1")).toBe("/dashboard?tab=1");
  });

  // 第4節のバイパス表を、そのまま実行可能な仕様として固定する
  it.each([
    "//evil.example", // プロトコル相対
    "/\\evil.example", // バックスラッシュ（\→/ 正規化で //evil 相当）
    "https://yourapp.com@evil.example", // userinfo 詐称
    "https://yourapp.com.evil.example", // サブドメイン詐称
    "javascript:alert(document.cookie)", // 危険スキーム
  ])("バイパス入力 %s は fallback に倒す", (input) => {
    expect(toSafeRelativePath(input)).toBe("/dashboard");
  });

  it("空・null・undefined は fallback に倒す", () => {
    expect(toSafeRelativePath(null)).toBe("/dashboard");
    expect(toSafeRelativePath("")).toBe("/dashboard");
    expect(toSafeRelativePath(undefined)).toBe("/dashboard");
  });
});

テストが緑なら「よくあるバイパスは弾けている」ことの機械的な証拠になります。ただし——これは「許可先の設計が正しい」ことの証明ではありません（第7節）。テストが守るのは「壊れていないこと」であって、「仕様が正しいこと」ではない。この区別は最後まで意識してください。

6. クライアント遷移の追加リスク——javascript: と location

サーバーのHTTPリダイレクト（Location ヘッダ）では javascript: スキームは実行されません。しかしクライアント側の遷移——window.location.href = next や router.push(next)、<a href={next}>——では話が変わります。

"use client";
// 脆弱：javascript: / data: スキームがそのまま実行されうる（DOM XSS）
function goBack(next: string) {
  window.location.href = next; // next="javascript:alert(document.cookie)" で発火
}

つまりクライアント遷移は、**オープンリダイレクト（外部ホストへの転送）に加えて、スキーム経由のスクリプト実行（DOM XSS）**という二重のリスクを負います。対策は同じく toSafeRelativePath() で相対パスに正規化してから渡すこと。外部URLを許す場合も、https: 以外のスキームを toAllowlistedUrl() で確実に排除します。この javascript: / data: スキームの実行は本質的にDOM XSSの一種であり、その仕組みと対策はDOM XSSとdangerouslySetInnerHTMLの対策で詳しく掘り下げています。

7. taintで検出する——汚染入力→redirectシンク

オープンリダイレクトは、**「クライアントが操作できる入力（source）が、検証されないまま遷移シンク（sink）に到達する」**という共通構造を持ちます。だから正規表現ではなく、関数内のデータフロー（taint解析）で機械的に追えます。

私が公開しているOSS Aegisは、この「source→（検証を経ずに）sink」のパスを検出します。インストール不要・設定不要で走ります。

# 汚染入力→redirectシンクのデータフローを可視化する
npx @aegiskit/cli scan

検出ロジックは、searchParams.get 等の汚染源から redirect 系シンクまでの経路に、new URL での解決＋オリジン照合や allowlist 照合のような『検証ノード』が挟まっているかを見ます。挟まっていなければ「未検証のリダイレクト」として指摘します。

正直なスコープ。 taint解析が機械的に見つけられるのは「検証なしで入力が遷移シンクに届いている」という事実までです。「どの遷移先を許すべきか」——allowlistに載せるホスト、ログイン後にどこへ戻すかという業務上の正解——は、ツールには決められません。それはあなたのアプリの仕様であり、コードの外形からは導けない設計判断だからです。データフロー解析は関数内（intraprocedural）が基本で、モジュールやフレームワークを跨ぐ流れは見逃します。クリーンな結果は「よくある罠は踏んでいない」であって「安全」ではありません。 この検出は、人間のレビューと脅威モデリングを置き換えるものではなく、補完するものです。

8. 本番前チェックリスト

外注でもAI製でも、本番投入の前に最低限これだけは確認してください。

• redirect() / NextResponse.redirect() / router.push() に、searchParams・formData・cookies 由来の値を素通しで渡していない
• 既定は new URL で解決しオリジン照合した相対パスだけを許可している（前方一致チェックではない）
• 外部遷移は host完全一致のallowlist＋スキーム固定（https） でのみ許可している
• //evil・/\evil・yourapp.com@evil・yourapp.com.evil のバイパス入力を実際に試した（200で自社に留まるか）
• 認証コールバック（/auth/callback 等）の next を検証している（最も漏れやすい経路）
• ログイン後の callbackUrl を検証している（認証直後の最も危険な遷移）
• クライアント遷移で javascript: / data: スキームを排除している（DOM XSS対策）
• middlewareの redirect の戻り先 (from) を検証している。rewrite に利用者URLを渡していない
• taintスキャン（npx @aegiskit/cli scan）をCIに常設し、未検証リダイレクトの再混入を止めている

発注者の視点で最も効くのは、**「?next=//evil.example を付けたらどこに飛びますか？」「ログイン後の戻り先はどうやって検証していますか？」**の2問です。良い開発者は即答できます。

9. どこまで自分で、どこから監査か

正直に線を引きます。

「未検証のリダイレクトを見つける」ところまでは、自動化で機械的に潰せます。 汚染入力から遷移シンクへの経路を追うtaint解析をCIに入れ、toSafeRelativePath() / toAllowlistedUrl() のような検証関数を1か所に集約すれば、人間が毎回考える必要はありません。まずは Aegis（無料OSS、npx @aegiskit/cli scan）で現状を可視化するのが、最もコスパの良い第一歩です。

一方、「どこへの遷移を許すか」という許可先の設計は、人間の領域です。 allowlistに載せるべきホスト、認証後の正しい戻り先、外部決済からの復帰フロー——これらはあなたの業務とデータモデルを理解した人間にしか決められません。ここで「導入すれば安全」と言い切るツールは、むしろ危険です。Aegisは未検証リダイレクトを検出・警告しますが、許可先の設計が正しいことは証明しません。完全に安全にする魔法はありません。

だからこそ線引きが要ります。どこまで自分で固め、どこから専門家のレビューが要るか——既存のNext.jsアプリで認証フローやリダイレクトの設計レビューが必要なら、セキュリティ監査で承ります。私自身、木材流通業界のDX案件で、認証・テナント分離・遷移制御を含むアプリ層の認可を実運用で設計・検証してきました。

よくある質問（FAQ）

Q. redirect() に相対パスしか渡さなければ、検証は不要ですか？ A. その値が定数なら不要です。問題になるのは searchParams や formData 由来の動的な値を渡すときだけ。動的な値は短い相対パスに見えても //evil や /\evil に化けるため、必ず toSafeRelativePath() を通してください。

Q. allowlistは正規表現で書いてはいけませんか？ A. 避けるべきです。/yourapp\.com/ のような正規表現は yourapp.com.evil.example にもマッチします。new URL で hostname を取り出し、Set で完全一致照合するのが安全です。サブドメインを許すなら先頭のドットでアンカーします。

Q. プロトコル相対 (//) さえ弾けば十分ですか？ A. 不十分です。円記号 (/\evil) は \→/ の正規化で //evil と等価になり、startsWith("//") をすり抜けます。さらに @（userinfo）やサブドメイン詐称もあります。個別パターンを潰すより、new URL で解決してオリジンを照合する1つの判定に寄せるのが堅実です。

Q. Auth.js（NextAuth）やSupabaseを使っていれば自動で安全ですか？ A. フレームワークの既定の redirect コールバックは多くの場合、同一オリジン/相対のみ許可します。しかしカスタムの redirect コールバックで生の値を返したり、/auth/callback の next を自前で転送したりすると、その瞬間に穴が戻ります。フレームワーク任せにせず、自分で書いた遷移経路は必ず検証してください。

Q. オープンリダイレクトはWAFで止められますか？ A. 止められません。?next=https://evil.example は認証も書式も正しい「正規リクエスト」で、攻撃か否かは「このアプリがどの遷移先を許すか」というアプリ固有のルールでしか決まらないからです。WAFはあなたの許可ポリシーを知りません。コード側の検証が唯一の防御です。

まとめ：遷移先は「文字列」ではなく「構造」で判断する

要点を整理します。

• オープンリダイレクトは、信頼できる自社ドメインを起点に攻撃者ドメインへ転送させる欠陥。フィッシングと、認証直後のトークン窃取の踏み台になる。
• Next.jsでは redirect(searchParams.next)・ログイン後の callbackUrl・OAuthコールバックの next・middlewareの redirect が典型的な発生箇所。redirect() は絶対URLを渡せば外部にも飛ぶ。
• 素朴な文字列チェックは破られる——//evil（プロトコル相対）、/\evil（円記号）、yourapp.com@evil（userinfo）、yourapp.com.evil（サブドメイン詐称）。遷移先は文字列ではなく**構造（origin/host/scheme）**で判断する。
• 防御の既定は「new URL で解決しオリジン照合した相対パスのみ許可」。外部遷移は host完全一致のallowlist＋https固定で例外的に許す。返す値はパス成分だけに削る。
• 汚染入力→redirectシンクのデータフローはtaint解析で機械的に検出できる（npx @aegiskit/cli scan）。ただし許可先の設計は人間の判断であり、ツールは検出を助けるだけで正しさは証明しない。

AIで速く作ること自体は正しい。速く作ったものを、漏らさず安全に固める——その仕組みづくりや、既存のNext.jsアプリの認証フロー・リダイレクト設計のレビューが必要であれば、お気軽にご相談ください。

参考資料

• OWASP Top 10
• OWASP Web Security Testing Guide（リダイレクト検査の指針）
• OWASP Application Security Verification Standard（ASVS／許可先のallowlist検証要件）