Next.jsのセキュリティ対策チェックリスト：情シスが確認すべき項目の整理方法

なぜNext.jsは「放っておくと危ない」のか：情シスが押さえるべき全体像

Next.jsは、WebサイトやWebアプリを作るためのフレームワークで、表示速度や開発効率に強みがあります。一方で、Next.jsは「フロント（画面）」だけでなく「サーバー側の処理」まで同じ仕組みで動くため、設定や運用が雑だと、攻撃者から見える“入口”が増えやすい点が重要です。情シスとしては、開発チームが「機能を作る」ことに集中しがちなぶん、守りの観点でチェック項目を型化しておく必要があります。

Next.jsのセキュリティは、大きく分けて以下の層で考えると整理しやすくなります。

• アプリ設計・実装：ログイン、権限、入力チェック、ファイルアップロード、APIなどの作り方
• Next.js固有の設定：SSR/SSG、API Routes、Middleware、Image最適化、リダイレクトなど
• 依存関係：Next.js本体、React、npmパッケージの脆弱性
• インフラ・配信：CDN、WAF、TLS、ヘッダー、環境変数、監視、バックアップ
• 運用・ガバナンス：変更管理、脆弱性対応のSLA、ログ保全、権限管理、教育

情シスが目指すべきは、「全部を自分で理解してレビューする」ではなく、最低限の“確認ポイント”をチェックリスト化し、開発・運用のフローに組み込むことです。特に中小企業でも予算がある場合は、外部ベンダーに委託するケースも多いですが、その際も「委託したから安心」ではなく、納品物や運用手順が安全かを確認できる形にするのがポイントです。

以降では、Next.jsのセキュリティ対策を「情シスが確認しやすい順」に並べ、具体的に何を見ればよいか、現場でよく起きる失敗も含めて整理します。

まず作る：情シス向け「Next.jsセキュリティチェックリスト」の整理方法

チェックリストは、ただ項目を羅列しても運用されません。実務では「誰が、いつ、何を、どの証跡で確認するか」まで落とすと回り始めます。Next.js案件でおすすめの整理方法は、次の3階層です。

次に「確認のタイミング」を決めます。Next.jsのように更新が多いプロジェクトでは、年1回の棚卸しだけだと追いつきません。推奨は以下です。

• 要件定義・設計：認証方式、権限、データ分類、外部連携、ログ要件
• 開発中（PR/CI）：依存関係スキャン、Lint、テスト、シークレット検知
• リリース前：設定値、ヘッダー、ビルド成果物、脆弱性修正状況、手順書
• 運用中：監視、アラート、ログ保全、月次パッチ、インシデント訓練

そして「証跡」を決めます。情シスが確認しやすい証跡例は、CIの実行結果、設定ファイルの該当箇所、スクリーンショット、ログのサンプル、運用Runbook（手順書）です。口頭説明だけで完了にしないのが監査・事故対応の観点で重要です。

以降の章では、チェック項目を「アプリ」「Next.js設定」「依存関係」「インフラ」「運用」に分けて具体化します。必要に応じて、そのままチェックリストに貼れる形で記載します。

アプリの基本：認証・認可・入力・セッション（最優先チェック）

Next.jsを使っていても、攻撃の多くは「ログイン周り」「権限の抜け」「入力の不備」に集中します。情シスとしては、まずここを必須項目にします。専門用語が出ますが、業務イメージで言うと「社員証（ログイン）」「入退室権限（閲覧・編集できる範囲）」「申請書の記入ミス（入力）」「受付票の使い回し（セッション）」を想像すると理解しやすいです。

認証（ログイン）で確認すること

• 方式：社内向けはSSO（Azure AD/Google Workspace等）優先。外部向けはMFA（多要素認証）を基本方針にする
• パスワード運用：自前実装を避け、実績ある認証基盤（例：OIDC）に寄せる。初期パスワード配布・リセット手順も確認
• アカウント列挙対策：「そのメールは存在しません」などのメッセージでユーザー存在が分からない設計
• ブルートフォース対策：一定回数失敗で一時ロック、レート制限、CAPTCHA等の方針

認可（権限）で確認すること

「ログインできる」ことと「そのデータを見て良い」ことは別です。Next.jsではAPI RoutesやServer Actions、外部API呼び出しが混在しやすいため、画面の表示制御だけでなく、サーバー側で権限チェックが必ずあることを確認します。

• 権限モデル：管理者/一般/閲覧のみ等を定義し、要件定義書や設計書に残す
• API側の検証：URLを直接叩いても他人のデータが取れない（IDを書き換えても無効）
• 管理画面の保護：/admin 等のパスは認証必須＋MFA＋IP制限（可能なら）

入力・ファイルアップロードで確認すること

• 入力検証：必須/形式/長さをサーバー側でも検証（クライアント側だけに依存しない）
• XSS対策：ユーザー入力をHTMLとして表示する場合はサニタイズ。WYSIWYGやMarkdown変換は要注意
• ファイル：拡張子ではなくMIMEや中身を確認、サイズ制限、ウイルススキャン、公開URLの扱い
• パス・URL：外部URLを渡して取得する機能（画像取得など）はSSRFの温床。許可リスト方式に

セッション/トークンで確認すること

• Cookie設定：Secure（HTTPSのみ）、HttpOnly（JSから参照不可）、SameSite（基本Lax/Strict）
• 有効期限：長すぎないか、端末紛失時に失効できるか（強制ログアウト）
• CSRF対策：Cookie認証の場合はCSRFトークンやSameSite設計、重要操作は再認証も検討

よくある失敗は、「画面では隠しているから大丈夫」と思い込むことです。攻撃者は画面を操作せず、APIを直接叩きます。情シスとしては、“サーバー側で最終判断しているか”を必須の観点として押さえてください。

Next.js固有の注意点：SSR/SSG、API Routes、Middleware、エラーページ

Next.jsは「ページ表示の仕方」が複数あり、設定次第で情報漏えいや権限抜けが起きます。情シスが全実装を追わなくても、確認すべきポイントは絞れます。

SSR/SSG/ISRの使い分けと情報漏えい

Next.jsでは、サーバーで都度生成（SSR）、ビルド時に静的生成（SSG）、一定間隔で再生成（ISR）といった方式があります。ここでの事故は、「ログイン後の個別情報を、静的生成してしまい第三者に見える」です。

• 個別情報のページ：原則SSR（またはサーバー側認証＋キャッシュ制御）にし、SSG/ISRにしない
• キャッシュ方針：CDNやブラウザキャッシュで「共有キャッシュ」されない設計か確認
• プレビュー機能：下書き閲覧のURLが推測可能になっていないか（トークン化、期限）

API Routes / Server Actionsの防御

Next.jsはアプリ内にAPIを持てます。便利な反面、社内開発だと「とりあえずAPIを生やす」になりがちです。チェック観点は以下です。

• 認証：全APIが認証前提か。例外（公開API）があるなら一覧化
• 権限：ユーザーIDを受け取って処理する設計は要注意（サーバーでユーザー確定）
• レート制限：ログイン・検索・CSV出力など重いAPIはDoSの入口。IP/ユーザー単位で制限
• 入力検証：型チェック、想定外データ、巨大ペイロードの拒否

Middleware/Redirect/Rewritesの落とし穴

• 認証ガード：Middlewareで認証している場合、対象パスが漏れていないか（/api、/admin、/internal等）
• オープンリダイレクト：redirect先URLをユーザー入力に任せない（フィッシング誘導に悪用）
• ヘッダーの一貫性：一部ルートだけCSPが無い、などのムラをなくす

エラー表示・ログ出力に秘密情報が混ざらないか

Next.jsでは開発時のエラーが分かりやすい反面、本番での設定やログ設計を誤ると、スタックトレースや環境変数が漏れることがあります。

• 本番は詳細エラーを出さない：ユーザーには一般的なエラー、詳細はログへ
• ログのマスキング：パスワード、アクセストークン、個人情報をログに残さない
• ソースマップ：公開環境で意図せず配信しない（攻撃者に内部構造を渡す）

情シスの確認としては、「どのページが静的生成か」「認証が必要なURL一覧」「公開API一覧」「本番のエラーポリシー」を提出させると、Next.js固有の事故をかなり減らせます。

依存関係・ビルド・シークレット：アップデート前提で安全を保つ

Next.jsは進化が早く、Reactや周辺パッケージも含めると依存関係が多くなります。脆弱性は「作り方」だけでなく「古いまま動いている」ことで起きるため、情シスは運用ルールを決めておくべきです。ポイントは、“一度作ったら終わり”ではなく、月次で安全を維持する仕組みにすることです。

依存関係（npm）脆弱性の管理

• スキャン：CIで依存関係スキャンを必須化（例：npm audit相当、GitHub Dependabot等）
• 対応期限：重大（Critical/High）は原則○日以内にアップデート、例外は承認制
• ロック：lockファイル（package-lock/yarn.lock/pnpm-lock）を管理し、勝手に変わらないように
• 不要削除：使っていないパッケージを減らす（攻撃面を減らす）

ビルド成果物と公開範囲

Next.jsのビルドは、静的ファイルやサーバーコードが混ざります。誤った成果物公開は事故につながります。

• 公開して良いもの：静的アセット、必要なサーバーバンドルのみ
• 公開してはいけないもの：.env、鍵ファイル、社内ドキュメント、テストデータ、管理用スクリプト
• ディレクトリ一覧：デプロイ対象のパスを明文化し、手動手順を排除（自動化）

環境変数・シークレット（最重要）

Next.jsでは環境変数を扱いやすい反面、フロント側に出してはいけない値が混ざる事故が頻発します。ルールとしてはシンプルで、ブラウザに配られる値は「公開情報」だと割り切ることです。

• 区別：「ブラウザに渡す環境変数」と「サーバーのみ」の区別を開発標準にする
• 保管：Secrets Manager等に保管し、リポジトリや共有フォルダに置かない
• ローテーション：漏えい前提で定期更新（特に外部APIキー）
• スキャン：コミット前後でシークレット検知（誤コミットを検出）

サプライチェーン（委託先・外部コード）のリスク

• 委託先の開発環境：権限、2FA、端末管理、退職者のアクセス削除の確認
• 外部スニペット：貼り付けコード（解析タグ等）の棚卸し。必要最小限に
• リリース権限：本番デプロイ権限を最小化し、承認フローを設ける

情シスの実務としては、「月次で依存関係スキャンの結果が提出される」「Critical/Highの未対応がゼロまたは例外承認」の形にできると、Next.jsに限らずWeb全体の防御力が上がります。

インフラ・配信（CDN/WAF/TLS/ヘッダー/ログ）：情シスが主導しやすい領域

アプリの中身に詳しくなくても、情シスが効果を出しやすいのがインフラ・配信の統制です。Next.jsはVercel等のPaaSで動かす場合も、AWS等で自前運用する場合もありますが、共通して「外から見える入口」を固めることが重要です。

TLS（HTTPS）とドメイン管理

• HTTPS強制：HTTPアクセスをHTTPSへリダイレクト
• 証明書：自動更新の仕組み、期限切れ監視
• ドメイン：DNSの変更権限を最小化。レジストラに2FA、ロック設定

セキュリティヘッダー（まずは最低ライン）

ブラウザ側での防御を強化するヘッダーは、導入効果が高い一方で、いきなり厳格にすると画面崩れ等が起きます。情シスとしては「最低ライン→段階的に強化」の方針が現実的です。

• CSP：まずはレポートモードや緩めのポリシーから開始し、徐々に制限
• X-Content-Type-Options：推測を防ぐ
• Referrer-Policy：外部送信される参照情報を抑制
• Permissions-Policy：不要なブラウザ機能を無効化
• HSTS：HTTPS固定化（導入前に影響範囲を確認）

WAF・レート制限・Bot対策

• WAF：OWASP系の代表的攻撃（SQLi/XSS等）をまずブロック、誤検知は運用で調整
• レート制限：ログイン、検索、ファイル生成、問い合わせ等を保護
• Bot対策：フォーム荒らし、スクレイピング対策（必要に応じて）

ログ・監視・アラート（事故対応の生命線）

インシデント時に困るのが「ログがなくて原因が追えない」「誰が何をしたか分からない」状態です。Next.jsアプリでは、フロント・サーバー・CDN・認証基盤とログが分散しやすいため、最低限の設計が必要です。

• 監視対象：5xx増加、認証失敗急増、レート制限発火、管理画面アクセス増、外部API異常
• ログ保全：保存期間（例：90日〜1年）、改ざん耐性、アクセス権
• 個人情報：必要最小限。IPやユーザーIDの扱いは社内規程に合わせる

バックアップと復旧（RTO/RPO）

• 対象：DB、オブジェクトストレージ、設定、環境変数、鍵、重要ログ
• 復旧訓練：年1回でも良いので、実際に戻せるか確認
• ランサム対策：バックアップの隔離、削除保護

インフラ側は情シスが標準化しやすいので、Next.js案件が増えるほど効いてきます。特にWAF・TLS・ヘッダー・ログ保全は、アプリの作りに依存しにくい「即効性のある守り」です。

運用・体制：リリース前レビュー、脆弱性対応、インシデント手順を“回る形”にする

セキュリティは「対策の有無」より「運用で継続できるか」で差が出ます。Next.jsは更新頻度が高いため、運用が弱いとすぐに差分が溜まります。情シスが設計すべきは、チェックが自然に実行されるフローです。

リリース前レビュー（情シスの関与ポイント）

• 変更点の要約：機能だけでなく「セキュリティ影響（権限/データ/外部連携）」を1枚で提出
• チェック証跡：依存関係スキャン結果、テスト結果、設定差分、シークレット漏えい検知
• 例外管理：未対応項目は期限・リスク・暫定策・責任者を明記

脆弱性対応のSLA（いつまでに直すか）

「分かったけど忙しいから後で」が続くと、Next.jsや周辺パッケージの既知脆弱性が残ります。そこで、重大度ごとに対応期限を決めます。

• Critical：原則即時（当日〜数日）
• High：1〜2週間
• Medium：次の定例リリースで対応
• Low：棚卸しで整理し、優先度に応じて

ベンダー委託の場合は、SLAを契約・SOWに入れると運用が安定します。「誰が、いつ、判断するか」を決めておくだけで、事故の確率が大きく下がります。

インシデント対応：最低限のRunbook

• 初動：連絡網、権限者、外部公開の停止手順（メンテ表示等）
• 封じ込め：キー失効、パスワードリセット、WAF強化、該当機能の一時停止
• 調査：どのログを見るか、保全方法、タイムラインの作り方
• 再発防止：チェックリストへの反映、テスト追加、承認フロー改善

監査・社内説明に効く「成果物」

情シスが社内外（経営層、監査、取引先）に説明するために、次の成果物を揃えると強いです。

• URL一覧：公開/要認証/管理/内部APIの分類表
• データ分類：個人情報・機密情報の取り扱い（保存先、暗号化、アクセス権）
• 運用手順：パッチ、アラート対応、権限付与/剥奪、バックアップ復旧
• チェックリスト：必須/推奨/改善の3階層＋証跡欄

Next.jsのセキュリティは技術論に寄りがちですが、情シスの価値は「組織として再現できる形」に落とすことです。ここまで整えると、担当者が変わっても品質を維持しやすくなります。

まとめ

Next.jsは高速で柔軟な一方、SSR/SSG、API Routes、Middleware、依存関係など「入口」が増えやすく、放置すると事故につながります。情シスがやるべきことは、細かい実装を全部理解することではなく、確認ポイントをチェックリスト化し、設計・開発・リリース・運用の各タイミングに組み込むことです。

• 最優先：認証・認可・入力検証・セッション（サーバー側で最終判断）
• Next.js固有：SSR/SSG/ISRとキャッシュ、API防御、リダイレクト、エラー表示
• 運用の要：依存関係スキャン、シークレット管理、アップデートSLA、ログ保全
• 情シス主導で効く：TLS、WAF、セキュリティヘッダー、監視・アラート

「チェックリストの雛形が欲しい」「委託先の納品物をどう評価すればよいか分からない」「既存のNext.jsサイトを短期間で棚卸ししたい」といった場合は、現状の構成と運用を見える化するだけでも効果が出ます。