本文へスキップ
>_ITDITDセキュリティ対策プラットフォーム

フレームワーク別

#Next.js#フレームワーク#アクセス制御#依存管理

Next.jsのセキュリティ対策 — 本番ハードニング実務リファレンス

Next.jsを安全に運用するための実務リファレンス。優先度つきハードニング・チェックリスト、サーバー/クライアント境界と環境変数・依存CVE(本体RCE含む)・Server Actions/Route Handlersの認可と入力検証・SSRF・セキュリティヘッダ/CSP・認証/セッション・レート制限の各対策、そして自己検証まで。攻撃手順は載せず防御と点検のみ。

公開日 2026-07-02 更新日 2026-07-02 10分で読める

対象：Next.js（App Router 想定）でアプリを運営している人。ここでは攻撃手順は扱わず、本番を固めるための実務リファレンス（優先度つきチェックリスト・領域別対策・自己検証）を示します。フレームワーク全体の考え方は フレームワーク別セキュリティの入口 も参照。

優先度つきハードニング・チェックリスト

まずこの表を上から実施します。P0は前提、P1が最頻の事故源、P2は継続的な運用衛生です。

P0 ── 前提（まずこれ）

秘密（APIキー等）をブラウザに出さない ／ 依存CVE監視＋即パッチ ／ 本番設定を固める

P1 ── 最頻の事故源

Server Actions/Route Handlers の認可＋入力検証 ／ サーバー側fetchのSSRF対策

P2 ── 運用衛生

ヘッダ/CSP ／ 認証・セッション・Cookie ／ レート制限

ハードニングは土台から積む。P0（前提）→P1（最頻の事故源）→P2（運用衛生）。
優先対策具体（Next.js）
P0秘密をブラウザに出さないNEXT_PUBLIC_ はブラウザ可の値だけ。秘密は Server Component/Action/Route Handler 内のみ
P0依存CVE監視npm audit/osv-scanner で監視・実稼働版で判定し即パッチ。本体RCEに追従
P0本番設定本番ビルドで動かし、エラーで内部（スタック/環境変数）を外に出さない
P1アクションの認可Server Actions/Route Handlers に認証＋所有者スコープの認可を毎回
P1入力検証受け取り値をスキーマ検証（型・範囲・許可値）。クライアントを信用しない
P1SSRF対策サーバー側の外部URL取得は許可先限定＋内部IP/メタデータ遮断。画像リモートパターンを絞る
P2ヘッダ/CSPnext.config でセキュリティヘッダ・HSTS。App Routerは nonce ベースのCSPを検討
P2認証/CookieセッションCookieに Secure/HttpOnly/SameSite。認可はミドルウェア任せにしない
P2レート制限認証・Server Actions・Route Handlers に試行/流量の制限

1. サーバー/クライアントの境界と環境変数（P0）

Next.js最大の事故源は、サーバー専用のはずの秘密がクライアントに載ってしまうことです。

  • NEXT_PUBLIC_ を付けてよいのはブラウザに出してよい値だけ。APIキー・接続情報など秘密には付けない（NEXT_PUBLIC_ はビルド時にクライアントバンドルへ焼き込まれ、閲覧者から見える）。
  • 秘密は Server Component / Server Actions / Route Handler の中だけで読み、props やレスポンス（シリアライズされる値）に混ぜない。
  • サーバー専用モジュールはクライアントから import されない設計に保つ（誤って持ち込まれると秘密が同梱され得る）。用語は .envと秘密情報 を参照。

2. 依存CVEと本体（P0）

  • 依存(npm)のCVEを npm audit や osv-scanner で機械監視し、実稼働版で判定して素早くパッチする（package.json の宣言でなく実際に入っている版で判断）。
  • Next.js 本体は過去に深刻なRCEも出ているため、公開されたら素早く追従する。運用のしくみは CVEに後れを取らないしくみ、実務は 脆弱性対応の実務。
  • Node/Next をサポート対象バージョンに保ち、EOL版を放置しない。

3. Server Actions / Route Handlers（認可＋入力検証・P1）

これらは公開されたサーバーの入口です。呼び出せる＝実行してよい、ではありません。

やりがち（危険）

  • アクションを「ログインしていれば実行可」に
  • ミドルウェアの認証だけを頼り、所有者チェックが無い
  • 入力を検証せずDBや外部呼び出しへ
  • クライアントから来た値（IDやフラグ）をそのまま信用

正しい

  • 認証に加えて所有者/権限スコープの認可をアクション/ハンドラ内で毎回
  • ミドルウェア任せにしない（認可はデータに近い場所で確認）
  • 入力をスキーマ検証（型・範囲・許可値）
  • IDの差し替え等に耐えるようサーバー側で再検証

用語は IDORとは。取得・更新・削除のすべての経路で所有者チェックを通します。

4. SSRF とサーバー側の外部取得（P1）

サーバーがユーザー指定のURLを取得する処理（画像プロキシ・Webhook・メタデータ取得等）はSSRFの入口です。

  • 取得先を許可リストに限定し、接続時にプライベートIP／クラウドのメタデータ(169.254.169.254)への到達を遮断する。
  • 画像最適化のリモートパターンを必要最小限に絞る（任意ホストの取得を許さない）。
  • 詳細は SSRFとは。当サイトも外部取得はSSRF安全ゲートウェイ経由にしている。

5. インジェクションと出力

  • XSS：Reactは既定で出力をエスケープする。dangerouslySetInnerHTML にユーザー入力を渡さない（どうしても必要ならサニタイズ後に限定）。用語は XSSとは。
  • SQL/インジェクション：ORM/プレースホルダでバインドし、文字列連結でクエリを組まない（→ SQLインジェクションとは）。
  • eval 等の危険な評価に外部入力を渡さない。

6. セキュリティヘッダと CSP（P2）

  • next.config でセキュリティヘッダ（X-Content-Type-Options 等）と HSTS を付与。自サイトの状態は セキュリティヘッダ診断 で確認。
  • App Router では nonce ベースのCSP を検討（インラインスクリプトの無制限許可を避ける）。解析/広告タグとの両立は設計が要る点に注意。

7. 認証・セッション・Cookie（P2）

  • セッションCookieに Secure / HttpOnly / SameSite を設定する。
  • ミドルウェアの認証チェックだけに認可を委ねない——ミドルウェアは補助であり、実際の可否はアクション/ハンドラ/データ層で再確認する（経路によってはミドルウェアを迂回し得るため）。
  • ログイン時のセッション再生成・失効設計を行う。

8. レート制限（P2）

  • 認証・Server Actions・Route Handlers に試行/流量の制限をかけ、総当りや濫用・DoSを抑える。

検証：自分のNext.jsは固められているか

作ったら終わりでなく、点検して初めて完了です。以下は自分のサイト/環境に対する防御的な自己チェックです。

1

秘密がクライアントに漏れていないか

ブラウザの「ソースを表示」やバンドルで、APIキー等の秘密が含まれていないこと、NEXT_PUBLIC_ を秘密に付けていないことを確認。
2

本番でエラーが内部を出さないか

わざとエラーを起こし、スタックトレースや環境変数が外部に出ないことを確認。
3

アクションの認可が効くか

テスト環境で、他ユーザーのリソースIDを指定して Server Action/Route Handler が拒否されることを確認（取得・更新・削除）。
4

ヘッダ・依存・SSRF

自サイトを ヘッダ診断で確認、npm audit/osv がクリーンか、外部取得が内部IPへ到達しないかを確認。

当サイトの視点：本体より『境界と依存』を管理する

当サイトはNext.jsで動いており、守りの重心は派手な設定ではなく「サーバー/クライアントの境界」と「依存の鮮度」にあります。秘密は必ずサーバー側に留め、公開入口（Server Actions/Route Handlers）には認可と入力検証を必ず書き、依存は毎デプロイ前にCVE監査する。当サイトの出自も“放置CVEの自動悪用”という事故なので、依存の機械監視は最優先の習慣です。外部URLの取得はSSRF安全ゲートウェイを通し、内部IPやメタデータへ到達させません。

次に読む

よくある質問

QNext.jsで最初にやるべきセキュリティ対策は何ですか？
A

優先度P0の3つです。(1)秘密（APIキー等）をブラウザに出さない（NEXT_PUBLIC_ を付けるのはブラウザに出してよい値だけ。APIキーや接続情報には付けない）、(2)依存パッケージのCVEを機械監視し実稼働版で判定して即パッチする（本体のRCEを含む）、(3)本番設定を固める（本番ビルド・エラーで内部を出さない）。次に Server Actions / Route Handlers の認可と入力検証、SSRF対策へ進みます。

Q環境変数はどう扱えば安全ですか？
A

原則は『秘密はサーバーだけ』です。ブラウザに載せてよい値だけ NEXT_PUBLIC_ を付け、APIキー・接続情報など秘密には絶対に付けません（NEXT_PUBLIC_ はビルド時にクライアントバンドルへ焼き込まれ、閲覧者から見えます）。秘密はサーバーコンポーネント／Server Actions／Route Handler の中だけで読み、props やレスポンスに混ぜない設計にします。

QServer Actions で気をつけることは？
A

Server Actions や Route Handlers は『公開されたサーバーの入口』です。呼び出せる＝実行してよい、ではありません。ログイン（認証）に加えて、その操作対象が本当にそのユーザーのものかを毎回スコープする認可を書き、入力は必ず検証します（例：スキーマ検証）。ミドルウェアの認証だけに頼らず、アクション/ハンドラ側でも所有者チェックを行うのが安全です。

QSSRFにはどう備えますか？
A

サーバー側でユーザー指定のURLを取得する処理（画像プロキシ・Webhook・メタデータ取得等）が主な入口です。取得先を許可リストに限定し、接続時にプライベートIPやクラウドのメタデータ(169.254.169.254)への到達を遮断します。画像最適化のリモートパターンも必要最小限に絞ります。詳細は用語ページを参照。

Q依存パッケージ(npm)の脆弱性はどう管理しますか？
A

npm audit や osv-scanner で既知CVEを機械監視し、『実稼働版』で判定して素早くパッチします（package.json の宣言でなく、実際に入っている版で判断）。Next.js 本体は過去に深刻なRCEも出ているため、追従の速さが要です。加えて Node/Next をサポート対象バージョンに保ち、EOL版を放置しないこと。