中小企業のNext.jsフルスクラッチで、セキュリティをどう担保するか｜2026年版チェックリスト（認証・入力検証・脆弱性対策）

中小企業向けに Next.js のフルスクラッチ受託をやっていると、「Next.js って、セキュリティ的に大丈夫なんですか？」と聞かれることがよくあります。フレームワーク自体が新しいので不安、という方もいれば、社内に詳しい人がいないので何をすればいいか分からない、という方もいます。

結論から言うと、Next.js は「フレームワークを最新に保ち、認証・認可を正しい場所で行い、入力を検証する」という当たり前を積み重ねれば、中小企業の業務システムでも十分に安全に運用できます。逆に言うと、特別な銀の弾丸はありません。本記事では、2026 年 6 月時点の公式情報をもとに、中小企業向けフルスクラッチで「最低限ここまではやる」というセキュリティの総論を、受託の現場感で整理します。各論を深掘りしたい部分は、過去記事への内部リンクをたどってください。

まず最優先: Next.js 本体を最新に保ち、脆弱性パッチに追従する

セキュリティの話というと認証や暗号化を思い浮かべがちですが、中小企業の現場で最初にやるべきは「フレームワーク本体を最新に保つこと」です。これがいちばん事故が起きやすく、いちばん対策が簡単な領域だからです。

直近でも、2026 年 5 月に Vercel が Next.js の大型セキュリティリリースを出し、13 件のアドバイザリがまとめて修正されました。その中でも中小企業の業務システムに直接効くのが、App Router の middleware（プロキシ）による認可を迂回できる脆弱性です。特別に細工した .rsc / segment-prefetch のリクエストが、本来の middleware ルールにマッチせずに保護対象ページへ到達でき、認可チェックを飛ばして保護コンテンツが読めてしまう、というものでした（CVE-2026-44575 / GHSA-267c-6grr-h53f、CVSS 7.5。出典: Vercel: Next.js May 2026 security release、GitHub Security Advisory GHSA-267c-6grr-h53f）。

しかもこの修正には続きがあります。最初の修正（16.2.5）が Turbopack をバンドラに使っている場合に効かない、という取りこぼしが見つかり、修正は 16.2.6 で入りました（CVE-2026-45109）。Next.js 16 は Turbopack が標準バンドラなので、多くの新規案件が影響範囲に入ります。本記事執筆時点（2026-06-09）の安定版は 16.2.7 系なので、16.2.6 以降に上げておけば、この一連の middleware 迂回はふさがります（出典: Next.js 公式ドキュメント Version 16 アップグレード）。

中小企業向けの受託で私たちがやっているのは、地味ですが次の3つです。

• npm audit を CI に組み込み、本番に効く脆弱性が出たら気づけるようにする（ただし dev 依存だけの警告に振り回されないよう、production への影響を見極める）
• Next.js 本体のセキュリティリリースは公式ブログを監視し、出たら速やかに上げる運用にする
• 自動更新（Dependabot / Renovate）でパッチバージョンの追従を仕組み化する

「フレームワークを上げるだけ」で防げる事故をゼロにすることが、限られた予算でいちばん費用対効果の高いセキュリティ対策です。

認証は middleware だけに頼らず、データに近い場所で認可する

次に、認証（ログインしているか）と認可（その人にこの操作が許されているか）の話です。ここは設計の根っこなので、総論として外せません。

前章の middleware 迂回の脆弱性が象徴的ですが、middleware だけに認証・認可を寄せるのは危険というのが 2026 年時点の共通認識です。これは特定のバグだけの問題ではなく、設計思想の問題でもあります。2025 年に公開された CVE-2025-29927 でも、middleware ベースの認証の限界が広く知られるようになりました。

Next.js 公式のデータセキュリティガイドでは、middleware を入口の関門として使いつつ、実際の認可はデータに近い場所、すなわち Data Access Layer（DAL） に集約することを推奨しています。具体的には、データ取得・更新を行う関数を server-only なモジュールに閉じ込め、その中で「セッション検証 → 認可チェック → クエリ → DTO 返却」を行う形です。公式ガイドも、認証だけでなく「このユーザーがこのリソースを操作してよいか」という認可（IDOR 対策）まで確認すべきと明記しています。

中小企業向けでも、会員制サイトや業務システムを作る以上、認証基盤は避けて通れません。Firebase Authentication を使った会員制サイトの作り方は 【2026年版】Next.js 16 + Firebase Authentication で実現するセキュアな会員制サイト構築 にまとめているので、認証の実装イメージはそちらを参照してください。本記事はあくまで総論なので、「middleware を玄関、DAL を本人確認」という二段構えが基本、という点だけ押さえておけば十分です。

入力検証（Zod）と Server Actions の安全な使い方

3つ目は、外から来るデータを信用しない、という話です。フォーム入力、URL パラメータ、ヘッダー、searchParams ——クライアントから来る値はすべて簡単に改ざんできるので、サーバ側で必ず検証します。

私たちは入力検証に Zod を使っています。Server Actions やルートハンドラの入口で Zod スキーマを通し、想定外の値はそこで弾く。これだけで、型の取り違えや不正な値による事故がかなり減ります。

特に注意したいのが Server Actions です。Next.js 公式ガイドは、Server Actions を「常に到達可能な POST エンドポイント」として扱えと明記しています。エクスポートした Server Action は、アプリの UI を経由しなくても直接 POST で叩けるからです。ページ単位の認証チェックは Server Action には伝播しないので、各アクションの中で改めて認証・認可をやり直す必要があります。

この Server Actions のセキュリティは、本記事だけでは語り尽くせない深さがあります。Data Access Layer の具体的な置き方、Zod による入力検証、DTO 返却、エラーの分離まで踏み込んだ各論は、詳細編として 中小企業のNext.jsフルスクラッチで、Server Actions のセキュリティを現実的に守る｜Data Access Layer の置き方 に書いています。本記事で「Server Actions は危ない、DAL に認可を寄せる」というラインだけ掴んだら、実装に入る前にそちらを必読としてください。総論（本記事）と各論（DAL記事）をセットで読むのが、いちばん抜け漏れの少ない進め方です。

環境変数・シークレット管理と、依存パッケージの脆弱性

4つ目は、秘密情報の扱いと、自分たちが入れているライブラリの安全性です。地味ですが、漏れると一発で致命傷になる領域です。

環境変数については、Next.js の挙動を正しく理解しておく必要があります。NEXT_PUBLIC_ を付けた環境変数はクライアントに露出するので、本当に公開してよい値だけに使います。API キーや DB 接続情報のような秘密は、絶対に NEXT_PUBLIC_ を付けません。公式ガイドはさらに踏み込んで、「process.env を読むのは Data Access Layer だけにする」ことを推奨しています。秘密情報へのアクセス箇所を一箇所に絞れば、どこから漏れるかの監査が楽になるからです。

中小企業の現場でありがちな事故は、次のようなものです。

• .env ファイルを誤って Git にコミットしてしまう
• サーバ専用のはずのキーを、クライアントコンポーネントから参照してしまう
• ライブラリを入れっぱなしにして、既知の脆弱性が放置される

最初の2つは、.gitignore の徹底と server-only パッケージの活用で防げます。server-only を import したモジュールは、クライアントから import されるとビルドエラーになるので、サーバ専用ロジックの誤った混入を機械的に防げます。

依存パッケージの脆弱性は、前述の npm audit と自動更新で継続的に潰します。ここで AI 駆動開発の話とつながります。Cursor や Claude Code で実装を速くできるようになった分、ライブラリを気軽に増やしがちですが、増やしたパッケージは全部、自分たちの攻撃面になります。私たちは「AI に書かせる前提のルール」として、不要な依存を増やさない・追加する依存は監査する、という方針を Cursor と Claude Code をどう使い分けているか｜中小企業向け Next.js 受託の現場 のような運用ルールに落とし込んでいます。AI で速く作ることと、依存を絞って安全に保つことは両立できます。

デプロイ時の設定と、テストで「壊れていないこと」を担保する

最後に、出荷の手前でやるべきことです。コードが安全でも、デプロイ設定が緩いと台無しになります。

中小企業向けのフルスクラッチで、私たちが最低限確認しているのは次のあたりです。

• リバースプロキシ越しの構成では、Server Actions の serverActions.allowedOrigins を設定し、想定外のオリジンからの実行を弾く（公式が CSRF 対策として推奨）
• セキュリティ関連の HTTP ヘッダー（Content Security Policy 等）を必要に応じて設定する
• 本番ビルドで NEXT_PUBLIC_ に秘密が混入していないか、最終確認する
• エラー監視を入れ、本番で起きた異常に気づける状態にする（ログには個人情報を載せない）

そして、これらのセキュリティ設定が「入れた後に壊れていないこと」をテストで担保するのが大事です。認可チェックや権限分岐は、まさにテストすべき筆頭です。とはいえ中小企業の予算では全部はテストできないので、「何をテストしないか」を先に決める考え方が要ります。権限・金額・外部連携の境界に密度を寄せるテスト戦略は 中小企業のNext.jsフルスクラッチで、テストをどこまで書くか｜AI駆動開発時代の現実的なテスト戦略 にまとめているので、セキュリティ設定の回帰を防ぎたい方は合わせて読んでください。

業務システム全体をどう作り直すかという文脈は 【2026年版】中小企業の社内業務を Next.js で作り直す実務ガイド でも触れています。セキュリティは単独の工程ではなく、設計・実装・テスト・運用のすべてに薄く効かせるもの、というのが私たちの考え方です。

まとめ: 中小企業の身の丈で守るセキュリティ・チェックリスト

総論として、中小企業向け Next.js フルスクラッチで「最低限ここまではやる」を一覧にすると、こうなります。

• 本体を最新に: Next.js は 16.2.6 以降に上げ、middleware 迂回（CVE-2026-44575）等のパッチに追従する。npm audit と自動更新を仕組み化する
• 認可はデータに近い場所で: middleware だけに頼らず、Data Access Layer にセッション検証と認可を集約する
• 入力を信用しない: Server Actions・ルートハンドラの入口で Zod 検証。各アクション内で認証・認可をやり直す
• 秘密を漏らさない: NEXT_PUBLIC_ は公開値だけ。process.env は DAL に閉じ、server-only で誤混入を防ぐ
• 出荷前に固める: allowedOrigins 設定、セキュリティヘッダー、本番ビルドの最終確認、エラー監視
• 壊れていないことを担保: 権限・金額・外部連携の境界をテストで守る

特別なことは1つもありません。当たり前を、抜けなく積み重ねるだけです。

AI 駆動開発で実装は速くなりましたが、「どこに認可を置くか」「何を秘密として扱うか」という判断は、引き続き人間が責任を持つべき領域です。

「自社の Next.js システムのセキュリティが今のままで大丈夫か不安」「フルスクラッチで業務システムを作りたいが、セキュリティ設計から相談したい」という中小企業の方は、株式会社ゼットリンカーの無料相談フォーム からご相談ください。ご予算と要件をうかがったうえで、身の丈に合ったセキュリティ設計と見積りをご提案します。