Next.jsのApp Routerは、Server ComponentsとClient Componentsが混在し、Server Actionsによってクライアントから直接サーバー処理を呼び出せるという、従来のSPA＋APIサーバー構成とは大きく異なるレンダリングモデルを持っています。この構造は開発体験を大きく向上させる一方で、「認証・認可のチェックをどこに、どう実装するか」を誤ると、意図しないデータ漏洩や権限昇格につながるリスクを抱えています。本記事では、Next.jsで認証・認可を実装する際に見落とされがちな落とし穴と、実務で再現性のある対策手順を、コード例つきで整理します。
Next.jsにおける認証・認可の基本と、実装位置が重要になる理由
認証（Authentication）は「このユーザーは誰か」を確認する処理であり、認可（Authorization）は「このユーザーがこの操作・データにアクセスしてよいか」を判定する処理です。Next.jsのApp Routerでは、この2つのチェックを実装できる場所が複数存在します。
- Middleware（
middleware.ts） - Layoutコンポーネント（
layout.tsx） - Pageコンポーネント（
page.tsx） - Server Actions（
"use server"関数） - Route Handlers（
route.ts）
問題は、これらのうちどれか1箇所にだけ認証チェックを置いて「実装した気になってしまう」ケースが非常に多いことです。Next.jsのレンダリング・キャッシュの仕組みを正しく理解していないと、特定の条件下でチェックがスキップされたり、意図せず古い認可結果が使い回されたりする事態が起こり得ます。次章で、実際によくある失敗パターンを具体的に見ていきます。
よくある認証実装のリスクと落とし穴
1. Middlewareだけに認証を任せてしまう
Middlewareはリクエストの入口で一括してセッション有無をチェックできるため、「ログインしていないユーザーをログインページへリダイレクトする」用途には非常に便利です。しかし、Middlewareは実行環境の制約（Edge Runtime）からDBへの直接アクセスやNode.js専用ライブラリの利用が制限されることが多く、実際にはJWTの署名検証程度の軽量チェックにとどまるケースがほとんどです。その結果、「トークンが存在するかどうか」だけを見ていて、「トークンの有効期限切れ」「ロールベースの権限」「対象リソースの所有者チェック」まではMiddlewareでカバーされていない、という状態に陥りがちです。Middlewareを認可の唯一の砦にすると、これらの抜け漏れがそのまま脆弱性になります。
2. Layoutコンポーネントでの認証チェックの見落とし
App RouterのLayoutは、同じセグメント内を遷移する際に再レンダリングされない設計になっています。つまり、あるレイアウト配下のページ間をクライアントサイドナビゲーションで移動する場合、そのレイアウトの認証チェックロジックは初回訪問時にしか評価されません。「ログイン状態やロールがセッション中に変化する」ケース（例：管理者権限の剥奪、アカウント停止、多要素認証の再要求など）では、Layoutだけに認可判定を置くと、権限が失効したユーザーが引き続き保護ページを閲覧できてしまう可能性があります。認可は「ページ単位」かつ「アクセスの都度」評価されることが望ましく、Layoutは補助的な位置づけにとどめるべきです。
3. Server Actions内での認可検証漏れ
Server Actionsは、クライアントのフォームやボタン操作から直接サーバー関数を呼び出せる便利な仕組みですが、その関数は事実上「誰でも直接叩けるAPIエンドポイント」と同等です。フロントエンドのUIで「本人だけがこのボタンを押せるように見せている」ことと、「サーバー側で本人であることを検証している」ことはまったく別問題です。クライアントから送られてくるユーザーIDやリソースIDといったパラメータは、ブラウザの開発者ツールやカスタムリクエストで自由に書き換えられるため、Server Actionsの内部で必ず「現在のセッションから取得した本人情報」と「操作対象のリソースの所有者」を突き合わせる認可チェックを行う必要があります。この検証を省略し、クライアントから渡されたIDをそのまま信頼してDB更新を行う実装は、典型的なIDOR（Insecure Direct Object Reference）脆弱性につながります。
4. Server ComponentからClient Componentへの過剰なProps受け渡し
App RouterではServer Componentが取得したデータをそのままPropsとしてClient Componentへ渡すことができますが、このシリアライズされたPropsはブラウザに送信されるJavaScriptバンドル（RSC Payload）に含まれ、開発者ツールから閲覧可能になります。DBから取得したユーザーオブジェクトを一切加工せずにそのままClient Componentへ渡してしまうと、パスワードハッシュ、内部管理用フラグ、他ユーザーの個人情報、APIキーといった本来表示すべきでない情報まで、意図せずクライアントに露出することがあります。認証・認可の文脈では「ログイン中の本人には見せてよいが、DOM上に残したくない機微情報」の扱いにも注意が必要です。
具体的な対策実装手順
手順1: ページコンポーネント単位でセッション検証を必ず行う
Middlewareでの一次チェックに加え、実際に保護対象データへアクセスするPageコンポーネント（Server Component）自身の中で、セッションの有効性とロールを再検証します。これにより、キャッシュやナビゲーションの都合でMiddlewareを経由しないケースが仮にあっても、最終防衛線としてページ側で必ず認可判定が行われます。
// app/dashboard/settings/page.tsx
import { redirect } from "next/navigation";
import { getCurrentSession } from "@/lib/auth";
export default async function SettingsPage() {
const session = await getCurrentSession();
if (!session || !session.user) {
redirect("/login");
}
if (session.user.role !== "admin" && session.user.role !== "owner") {
redirect("/403");
}
const settings = await getSettingsForUser(session.user.id);
return 手順2: Server Actions内でリソース所有者を必ず突き合わせる
Server Actionsでは、引数として渡されたIDを信用せず、必ずサーバー側で取得したセッション情報と紐づけて処理対象を決定します。更新・削除系の操作では「そのリソースが本当にこのユーザーのものか」をクエリ条件に含めることが重要です。
// app/actions/updateProfile.ts
"use server";
import { getCurrentSession } from "@/lib/auth";
import { db } from "@/lib/db";
export async function updateProfile(formData: FormData) {
const session = await getCurrentSession();
if (!session) {
throw new Error("Unauthorized");
}
const displayName = String(formData.get("displayName") ?? "");
// クライアントから渡されたuserIdは使わず、
// セッションから取得した本人IDのみを更新条件にする
await db.user.update({
where: { id: session.user.id },
data: { displayName },
});
}
手順3: DTOパターンで必要最小限のフィールドのみを取得・受け渡しする
DBから取得したエンティティをそのままClient Componentへ渡すのではなく、表示に必要なフィールドだけを抽出したDTO（Data Transfer Object）を経由させます。SELECT句の段階で不要なカラムを取得しないようにすることも有効です。
// lib/dto/userDto.ts
type UserDTO = {
id: string;
displayName: string;
avatarUrl: string | null;
};
export function toUserDTO(user: {
id: string;
displayName: string;
avatarUrl: string | null;
passwordHash: string;
isSuspended: boolean;
}): UserDTO {
return {
id: user.id,
displayName: user.displayName,
avatarUrl: user.avatarUrl,
};
}
手順4: Middlewareは「最初の防波堤」として位置づけて併用する
Middlewareを廃止するのではなく、あくまで「未ログインユーザーを早期にログインページへ振り分ける」「明らかに権限のないパスへのアクセスを事前にブロックする」といった粗いフィルタとして活用し、最終的な認可判定はページ・Server Actions側で行う「多層防御（Defense in Depth）」の考え方を徹底します。
セッション・トークン管理で追加に確認すべきポイント
実装位置の整理に加えて、認証まわりでは以下のような基本的なセキュリティ設定も見落とされがちです。
- Cookieの属性設定：セッションCookieには
HttpOnly、Secure、SameSite=Lax（または要件に応じてStrict）を設定し、JavaScriptからの読み取りやCSRF経由での送信リスクを下げる。 - JWTの取り扱い：JWTをクライアント側のlocalStorageに保存するとXSS経由で窃取されるリスクが高まるため、可能な限りHTTPOnly Cookieで管理し、有効期限を短く設定してリフレッシュトークンと組み合わせる。
- 認証ライブラリの活用：Auth.js（旧NextAuth.js）、Lucia、Clerkといった実績のある認証ライブラリを利用する場合も、ライブラリが提供するのは主に認証（ログイン処理・セッション発行）までであり、ロールベースの認可判定はアプリケーション側で実装する責務が残ることを理解しておく。
- 多要素認証（MFA）と再認証：パスワード変更、支払い情報の変更、退会など重要度の高い操作の前には、セッションが有効でも再度パスワード入力やMFAを要求する「step-up認証」を検討する。
- ログと監視：認可エラー（403）や不審なアクセスパターンをログに残し、異常なリクエスト増加を検知できる体制を整える。
Next.js認証・認可 実装チェックリスト
- Middlewareのみに認証・認可を依存させず、Pageコンポーネント側でも必ずセッション・ロールを再検証しているか
- Layoutコンポーネントの認証チェックが、再レンダリングされないことを前提に補助的な位置づけになっているか
- すべてのServer Actionsの冒頭で、セッション取得と認可判定を行っているか
- Server Actionsの処理対象（更新・削除するリソース）を、クライアントから渡されたIDではなくセッションから取得した本人情報に基づいて特定しているか
- Server ComponentからClient Componentへ渡すPropsが、DTOなどで必要最小限のフィールドに絞られているか
- パスワードハッシュや内部フラグなど機微情報がRSC Payload経由でクライアントに露出していないか
- セッションCookieに
HttpOnly・Secure・SameSiteが適切に設定されているか - 重要操作の前にstep-up認証（再認証・MFA）の要否を検討しているか
- 認可エラーや異常アクセスをログとして記録し、監視できる体制があるか
まとめ
Next.jsのApp Routerは柔軟なレンダリングモデルゆえに、認証・認可を「どこか1箇所」に実装するだけでは不十分になりやすいアーキテクチャです。Middleware・Layout・Page・Server Actionsそれぞれの実行タイミングと制約を理解した上で、最終的なデータアクセスが発生する場所（PageコンポーネントとServer Actions）では必ずサーバーサイドでの認可チェックを行い、Middlewareはあくまで早期フィルタとして位置づける多層防御を徹底することが重要です。あわせて、Client Componentへ渡すデータの最小化、Cookieのセキュリティ属性、重要操作時の再認証といった基本的な対策を積み重ねることで、Next.jsアプリケーションにおける認証・認可まわりのセキュリティリスクを大きく引き下げることができます。
コメント