対象：Next.js（App Router 想定）でアプリを運営している人。ここでは攻撃手順は扱わず、本番を固めるための実務リファレンス（優先度つきチェックリスト・領域別対策・自己検証）を示します。フレームワーク全体の考え方は フレームワーク別セキュリティの一覧 も参照。
優先度つきハードニング・チェックリスト
まずこの表を上から実施します。P0は前提、P1が最頻の事故源、P2は継続的な運用で守る項目です。
P0 ── 前提（まずこれ）
秘密（APIキー等）をブラウザに出さない ／ 依存CVE監視＋即パッチ ／ 本番設定を固める
P1 ── 最頻の事故源
Server Actions/Route Handlers の認可＋入力検証 ／ サーバー側fetchのSSRF対策
P2 ── 継続的な運用
ヘッダ/CSP ／ 認証・セッション・Cookie ／ レート制限
| 優先 | 対策 | 具体（Next.js） |
|---|---|---|
| P0 | 秘密をブラウザに出さない | NEXT_PUBLIC_ はブラウザ可の値だけ。秘密は Server Component/Action/Route Handler 内のみ |
| P0 | 依存CVE監視 | npm audit/osv-scanner で監視・実稼働版で判定し即パッチ。本体RCEに追従 |
| P0 | 本番設定 | 本番ビルドで動かし、エラーで内部（スタック/環境変数）を外に出さない |
| P1 | アクションの認可 | Server Actions/Route Handlers に認証＋所有者スコープの認可を毎回 |
| P1 | 入力検証 | 受け取り値をスキーマ検証（型・範囲・許可値）。クライアントを信用しない |
| P1 | SSRF対策 | サーバー側の外部URL取得は許可先限定＋内部IP/メタデータ遮断。画像リモートパターンを絞る |
| P2 | ヘッダ/CSP | next.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は固められているか
作ったら終わりではありません。点検して初めて完了です。以下は自分のサイト/環境に対する防御的な自己チェックです。
秘密がクライアントに漏れていないか
NEXT_PUBLIC_ を秘密に付けていないことを確認。本番でエラーが内部を出さないか
アクションの認可が効くか
ヘッダ・依存・SSRF
npm audit/osv がクリーンか、外部取得が内部IPへ到達しないかを確認。当サイトの視点：重点はサーバー/クライアントの境界と依存の管理
当サイトはNext.jsで動いており、重点は特別な設定ではなく「サーバー/クライアントの境界」と「依存を最新に保つこと」にあります。秘密は必ずサーバー側に留め、外部から呼び出せる処理（Server Actions/Route Handlers）には認可と入力検証を必ず書き、依存は毎デプロイ前にCVE監査する。当サイトを始めたきっかけも「放置したCVEを自動で悪用された」事故なので、依存の機械監視は最優先の習慣です。外部URLの取得はSSRF安全ゲートウェイを通し、内部IPやメタデータへ到達させません。
次に読む
- 一覧：フレームワーク別セキュリティ（一覧） ／ Laravelのセキュリティ対策
- 依存：CVEに後れを取らないしくみ ／ 脆弱性(CVE)対応の実務
- 用語：IDORとは ／ SSRFとは ／ .envと秘密情報 ／ XSS
- ツール：セキュリティヘッダ診断
出典と確認範囲
以下は上記の設定・影響範囲・対策を確認するための原典です。2026年10月23日に参照先を確認しました。各版・構成の条件は原典で確認してください。チェックリストの優先順位や教訓は当サイトの整理であり、記事全体の再検証や安全性の保証を意味しません。