Next.jsのセキュリティヘッダーとCSP(nonce) — middleware 1枚で多層防御を自動化する

最初に結論を述べます。Next.js のセキュリティヘッダーは、middleware.ts 1枚に集約して自動化できる「水平統制」です。 ヘッダーはアプリ固有のデータモデルを一切知らなくても、全リクエストに一律で効きます。だからこそ「人間が毎回正しく書く」前提を捨て、設定で一度固めるのが正解です。唯一の例外が nonce 方式の CSP で、これだけは「リクエストごとに毎回生成」が必須なため、静的な設定ファイルでは表現できません——middleware で生成し、ヘッダーとアプリの両方へ受け渡す必要があります。

ただし、ここで一つ正直に線を引いておきます。CSP は XSS の「最後の砦」であって、出力の安全設計の代わりにはなりません。 汚染データを dangerouslySetInnerHTML に素通しすれば、CSP があっても被害は出ます。本記事は「ヘッダーで何を機械的に塞げるか」と「ヘッダーでは塞げない、設計が要る領域はどこか」をセットで、Next.js App Router の実コードと一次情報に基づいて整理します。これは Next.js × Supabase アプリケーションセキュリティで描いた「水平統制 vs 垂直リスク」の地図の、ヘッダー領域を深掘りする記事です。

1. なぜヘッダーは「自動化できる水平統制」なのか

セキュリティ対策には、性質の異なる2種類があります。

種別	例	何に依存するか	自動化
水平統制	セキュリティヘッダー、CSP、レート制限、CSRF、入力検証	アプリ横断で一律	設定で一律に肩代わりできる
垂直リスク	認可/IDOR、テナント分離、業務ロジック	「誰が何を所有するか」	検出・警告まで。修正は人間の設計

セキュリティヘッダーは完全に前者です。Strict-Transport-Security や X-Content-Type-Options: nosniff は、あなたのテーブル構造もユーザーの所有関係も知りません。ただ「全レスポンスに同じ1行を足す」だけで効きます。人間が画面ごとに考えるべきものではなく、1か所に集約して機械に番をさせるべき領域です。

Next.js でこの「1か所」になるのが middleware です。middleware.ts はすべてのリクエストの前段で走るため、ヘッダー付与の単一の関所として理想的です（Next.js docs）。next.config.js の headers() でも静的ヘッダーは付けられますが、後述する nonce はリクエストごとに値が変わるため、next.config.js では表現できません。だからヘッダー戦略は middleware に寄せるのが筋が通ります。

OWASP の Application Security Verification Standard（ASVS）も、セキュリティを「入れたか」ではなく「検証できるか」で測ります。本記事も各ヘッダーについて「何を塞ぐか」と「どう確かめるか」をセットで述べます。

2. 主要セキュリティヘッダーと、各々が塞ぐ脅威

まず地図を渡します。ヘッダーは「1個で全部を守る魔法」ではなく、1個が1つの脅威を塞ぐ部品の集合です。混同すると「CSPを入れたのにクリックジャッキングされた」のような事故になります。

ヘッダー	塞ぐ脅威	典型値
`Content-Security-Policy`	XSS（被害の縮小）、データ持ち出し	`default-src 'self'; script-src 'self' 'nonce-…'`
`Strict-Transport-Security`	HTTPSダウングレード、中間者(MITM)	`max-age=63072000; includeSubDomains; preload`
`X-Content-Type-Options`	MIMEスニッフィングによる誤実行	`nosniff`
`Referrer-Policy`	URL（トークン等）の外部漏洩	`strict-origin-when-cross-origin`
`frame-ancestors`（CSP）/ `X-Frame-Options`	クリックジャッキング	`frame-ancestors 'none'` / `DENY`
`Permissions-Policy`	カメラ/マイク/位置情報等の濫用	`camera=(), microphone=(), geolocation=()`

順に、要点だけ正確に押さえます。

Strict-Transport-Security（HSTS） は「このサイトは今後 max-age 秒間、必ずHTTPSで来い」とブラウザに強制します。初回アクセスの平文リクエストを後続で消すのが狙いで、preload を付けてブラウザの先読みリストに載せると初回も保護されます。ただし preload は一度載せると取り消しが難しいため、サブドメイン含め恒久的にHTTPS化できる確証がある場合だけにします（MDN Strict-Transport-Security）。

X-Content-Type-Options: nosniff は、ブラウザがレスポンスのMIMEタイプを「推測」して実行する挙動を止めます。例えばユーザーがアップロードしたファイルを、ブラウザが勝手に text/html と解釈してスクリプト実行する、という事故を防ぎます。値は nosniff 一択です。

Referrer-Policy は、別サイトへ遷移する際に送る Referer ヘッダーの粒度を制御します。クエリ文字列にトークンやセッションIDを載せている場合、これが緩いと外部サイトのアクセスログに秘密が漏れます。strict-origin-when-cross-origin（同一オリジンはフルパス、クロスオリジンはオリジンのみ）が実用的な既定です。

クリックジャッキング対策は、CSP の frame-ancestors が現代の正解です。古い X-Frame-Options は後方互換のために併記する程度で、frame-ancestors 'none'（または許可するオリジンを列挙）があれば本質的に十分です。両者が矛盾した場合は CSP が優先されます。

Permissions-Policy は、カメラ・マイク・位置情報・全画面などのブラウザ機能を、自サイトと埋め込みiframeのどちらに許すかを宣言します。使わない機能は camera=() のように空で明示的に閉じておくと、万一のXSSやサードパーティスクリプトによる濫用面が減ります。

ここまでの5つ（HSTS / nosniff / Referrer-Policy / frame-ancestors / Permissions-Policy）は値が固定です。リクエストによって変わりません。問題は6つ目、CSP の script-src だけが「リクエストごとに変わる値（nonce）」を必要とする点です。次節で深掘りします。

3. CSPの基礎 — default-src / script-src と、なぜ `'unsafe-inline'` が危険か

CSP（Content Security Policy）は「このページがどこからリソースを読み込み、何を実行してよいか」をブラウザに宣言するヘッダーです。XSS が混入しても、攻撃者のスクリプトを「許可されていない」として実行させないのが狙いです（MDN Content-Security-Policy）。

ディレクティブは「リソース種別ごとの許可リスト」です。最重要な数個だけ押さえます。

Content-Security-Policy:
  default-src 'self';                          # 既定: 同一オリジンのみ許可
  script-src 'self' 'nonce-rAndOm==';          # JS: 自オリジン + このnonce付きのみ
  style-src 'self';                            # CSS: 自オリジンのみ
  img-src 'self' data:;                        # 画像: 自オリジン + data URI
  object-src 'none';                           # <object>/<embed> 禁止（古い攻撃面を閉じる）
  base-uri 'none';                             # <base> 改ざんによる相対パス乗っ取りを防ぐ
  frame-ancestors 'none';                      # クリックジャッキング対策

default-src はフォールバックで、個別指定のないリソース種別すべてに適用されます。script-src がスクリプトの実行可否を握る最重要ディレクティブです。

なぜ `'unsafe-inline'` が危険か

ここが CSP の核心です。多くの「とりあえずCSPを入れた」設定は、こう書かれています。

# アンチパターン: これは「CSPを入れた」が「XSSをほぼ防げない」設定
script-src 'self' 'unsafe-inline';

'unsafe-inline' は「ページ内に直接書かれた <script>…</script> やインラインの onclick= を全部実行してよい」という許可です。しかしXSS の本質は、攻撃者がページにインラインスクリプトを注入することです。つまり 'unsafe-inline' を許した瞬間、CSP は XSS に対してほぼ無力になります。「鍵をかけたが、合鍵を玄関マットの下に置いた」状態です。

同様に 'unsafe-eval'（eval() や文字列からのコード生成を許可）も避けます。

正解: nonce + strict-dynamic

ではどうやって「自分の正規のインラインスクリプトだけ」を許すか。答えが nonce（number used once） です。リクエストごとにランダムな使い捨ての値を生成し、(1) CSP ヘッダーに 'nonce-<値>' として宣言し、(2) 自分が出力する <script> タグに nonce="<値>" 属性を付けます。両者が一致したスクリプトだけが実行されます。攻撃者は、サーバーがそのリクエストで生成したランダム値を事前に知り得ないため、注入したスクリプトに正しい nonce を付けられません。

# 厳格版: nonce で「正規のインラインだけ」を許可
script-src 'self' 'nonce-rAndOm==' 'strict-dynamic';

'strict-dynamic' は「nonce で信頼したスクリプトが、さらに動的に読み込むスクリプトも連鎖的に信頼する」指示です。これにより、ホスト名のallowlist（https://cdn.example.com のような列挙）に頼らずに済みます。allowlist 方式は、信頼したCDN上に1つでも悪用可能なスクリプトがあると破られるため、nonce + strict-dynamic の方が堅牢です。

決定的な制約がここにあります。nonce は「リクエストごとに必ず新しく生成」しなければ意味がありません。 全ユーザー・全リクエストで同じ固定値を使えば、攻撃者がその値を1度読み取るだけで自由にスクリプトを注入できてしまい、nonce を使う意味が消えます。だから nonce 付き CSP は、静的な next.config.js の headers() や、ビルド時に固定される設定では原理的に実現できません。リクエストのたびにコードが動いて値を作る場所——すなわち middleware が必要になります。

4. 実装 — middleware 1枚でnonceを生成し、ヘッダーとアプリへ受け渡す

ここが本記事の実装の核です。難しさは「生成した同じ nonce を、レスポンスヘッダーとレンダリングされる <script> の両方に行き渡らせる」という受け渡しにあります。Next.js App Router では、middleware からリクエストヘッダーに nonce を載せ、Server Component 側で headers() から読み取る、という経路が定石です。

4-1. middleware: nonce生成とヘッダー付与

// middleware.ts — リクエストごとに nonce を発行し、全ヘッダーを1か所で付与する
import { NextResponse, type NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  // リクエストごとに必ず新規生成。crypto は Edge ランタイムでも利用可
  const nonce = crypto.randomUUID().replace(/-/g, "");
  const isDev = process.env.NODE_ENV !== "production";

  const csp = [
    `default-src 'self'`,
    // 開発時は HMR のため eval を許す。本番ビルドでは付けない（下の分岐参照）
    `script-src 'self' 'nonce-${nonce}' 'strict-dynamic'${isDev ? " 'unsafe-eval'" : ""}`,
    // Next.js は styled-jsx 等でインラインstyleを使う。nonce が効かない環境向けの現実解は §6 で後述
    `style-src 'self' 'unsafe-inline'`,
    `img-src 'self' blob: data:`,
    `font-src 'self'`,
    `object-src 'none'`,
    `base-uri 'none'`,
    `form-action 'self'`,
    `frame-ancestors 'none'`,
    `upgrade-insecure-requests`,
  ].join("; ");

  // 1) 後段(Server Component)が同じ nonce を読めるよう、リクエストヘッダーに載せる
  const requestHeaders = new Headers(request.headers);
  requestHeaders.set("x-nonce", nonce);
  requestHeaders.set("Content-Security-Policy", csp);

  const response = NextResponse.next({ request: { headers: requestHeaders } });

  // 2) ブラウザに効かせる本番のヘッダー群（値が固定のものはここで一律付与）
  response.headers.set("Content-Security-Policy", csp);
  response.headers.set("X-Content-Type-Options", "nosniff");
  response.headers.set("Referrer-Policy", "strict-origin-when-cross-origin");
  response.headers.set("X-Frame-Options", "DENY"); // frame-ancestors の後方互換
  response.headers.set(
    "Permissions-Policy",
    "camera=(), microphone=(), geolocation=(), interest-cohort=()",
  );
  // HSTS は HTTPS 環境でのみ意味を持つ。ローカルHTTPで付けると後で苦労するので本番だけ
  if (!isDev) {
    response.headers.set(
      "Strict-Transport-Security",
      "max-age=63072000; includeSubDomains; preload",
    );
  }

  return response;
}

// 静的アセットやプリフェッチには CSP を流さない（不要なオーバーヘッドと誤検知を避ける）
export const config = {
  matcher: [
    {
      source: "/((?!api|_next/static|_next/image|favicon.ico).*)",
      missing: [
        { type: "header", key: "next-router-prefetch" },
        { type: "header", key: "purpose", value: "prefetch" },
      ],
    },
  ],
};

ポイントを3つ。(1) crypto.randomUUID() は Edge ランタイムでも使える標準APIで、外部依存なしに十分なランダム性が得られます（base64化したい場合は btoa だが、UUIDのハイフン除去でも実用上問題ありません）。(2) リクエストヘッダーとレスポンスヘッダーの両方に CSP を載せているのは、前者が「アプリへの受け渡し」、後者が「ブラウザへの適用」という別の役割だからです。(3) matcher で静的アセットを除外し、ヘッダー付与のコストとノイズを抑えます。

4-2. アプリ側: nonceを読んで `<script>` に付ける

middleware が x-nonce に載せた値を、Server Component で読み出します。

// app/layout.tsx — middleware が生成した nonce を読み、自前のインラインスクリプトに付与
import { headers } from "next/headers";
import Script from "next/script";

export default async function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  const nonce = (await headers()).get("x-nonce") ?? "";

  return (
    <html lang="ja">
      <body>
        {children}
        {/* 例: アナリティクス等の自前インラインスクリプトには必ず nonce を付ける */}
        <Script
          id="analytics-init"
          nonce={nonce}
          strategy="afterInteractive"
          dangerouslySetInnerHTML={{
            __html: `window.dataLayer = window.dataLayer || [];`,
          }}
        />
      </body>
    </html>
  );
}

headers() を呼ぶとそのルートは動的レンダリングになります。これは nonce 方式の本質的なトレードオフです——リクエストごとに値が変わる以上、そのページを静的にキャッシュすることはできません。完全静的配信が最優先で、かつ自前のインラインスクリプトが皆無なページでは、nonce を諦めてハッシュ方式（'sha256-…'）を選ぶ判断もあります。設計上の天秤として認識しておくべき点です。

4-3. 動作確認

実装したら、必ず「効いているか」を確かめます。型チェックや見た目では分かりません。

# レスポンスヘッダーを直接観測する。nonce がリクエストごとに変わることも確認
curl -sI https://localhost:3000/ | grep -iE "content-security-policy|strict-transport|x-content-type|referrer-policy|permissions-policy"

content-security-policy: default-src 'self'; script-src 'self' 'nonce-a1b2c3...' 'strict-dynamic'; ...
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
permissions-policy: camera=(), microphone=(), geolocation=(), interest-cohort=()

ブラウザのDevTools Consoleに Refused to execute inline script because it violates the following Content Security Policy directive という違反が出れば、それは「nonce の付け忘れたスクリプトが弾かれている」証拠です。次節の Report-Only を使えば、本番を壊さずにこの違反を観測できます。

5. Report-Only で段階導入する — いきなり強制しない

CSP を最初から強制（enforce）モードで本番投入するのは危険です。サードパーティのウィジェット、計測タグ、next dev の挙動、見落としていた自前インラインスクリプト——これらが一斉に弾かれ、画面が壊れます。正しい順序は「観測 → 修正 → 強制」です。

ブラウザはこのために Content-Security-Policy-Report-Only ヘッダーを用意しています。これは「ポリシーに違反するが、ブロックはせず違反だけを報告する」モードです。

// 段階導入: まず Report-Only で「何が弾かれるはずか」を観測する
const cspHeaderName = ENFORCE_CSP
  ? "Content-Security-Policy"
  : "Content-Security-Policy-Report-Only";

response.headers.set(cspHeaderName, csp);
// 違反レポートの送信先（report-to/report-uri）。収集は Sentry 等のエンドポイントでも可
response.headers.set(
  "Reporting-Endpoints",
  `csp-endpoint="https://example.com/api/csp-report"`,
);

導入手順は以下です。

Report-Only で本番にデプロイする。 画面は一切壊れません。
数日〜1〜2週間、違反レポートを集める。 実トラフィックでどのスクリプト/スタイル/接続先が弾かれるかが分かります。
正規のものをポリシーに足す。 自前スクリプトには nonce を付け、必要なサードパーティだけを許可に加えます。違反が枯れるまで繰り返します。
Content-Security-Policy（強制）へ昇格させる。 ここで初めてブロックが有効になります。

この「Report-Only で実トラフィックの違反を観測してから強制へ昇格」というプロセスを踏むかどうかが、CSP導入の成否を分けます。いきなり強制して障害を出し、CSP ごと外してしまう——これが最もよくある失敗です。

6. 正直な落とし穴 — Next.js特有の現実

実運用で必ずぶつかる点を、誇張せず挙げます。

インラインstyleの扱い。 Next.js は styled-jsx やフレームワーク内部のインラインスタイルを使う場面があり、style-src に nonce を効かせきれないことがあります。現実解は2つ——style-src 'self' 'unsafe-inline' を許容する（styleのインライン許可は、scriptのそれと比べてリスクは限定的だがゼロではないため、データ持ち出し系の攻撃面が残る点は認識する）か、ハッシュで個別許可する。完璧を狙って画面を壊すより、script-src を厳格に保ちつつ style-src は現実的に運用する方が、トータルのリスクは下がります。

サードパーティスクリプト。 計測・チャット・広告タグは、それぞれが要求するオリジンや 'unsafe-inline' 相当を持ち込みます。'strict-dynamic' を使えば多くは nonce 連鎖で動きますが、対応していないタグもあります。「CSPに合わないタグは入れない」という逆方向の意思決定も、セキュリティ上はしばしば正解です。

headers() による動的化。 §4-2 で触れたとおり、nonce を読むページはISR/静的キャッシュの対象外になります。CDNフルキャッシュが事業上クリティカルなページでは、ハッシュ方式や、そのルートだけCSPを緩める判断を要します。

middleware のランタイム。 middleware は Edge ランタイムで動くため、crypto.randomUUID() のような標準APIは使えても、Node.js固有のモジュールは使えません。nonce 生成にNode専用ライブラリを持ち込まないよう注意します。

これらはどれも「ヘッダーを入れれば終わり」ではなく、アプリの構成に合わせた調整が要ることを示しています。とはいえ調整の範囲はアプリ横断の設定の中に閉じており、データモデルの設計判断は不要です。だから依然として「水平統制＝自動化できる層」です。

7. これは「水平統制」— Aegisのinitで自動化できる

ここまでの実装は、突き詰めれば定型作業です。nonce 生成、ヘッダー6種の付与、Report-Only からの段階導入、matcher の設定——どれもアプリ固有の知識を要さず、正しく一度書けば全プロジェクトで使い回せます。「人間が毎回 middleware を手書きする」より、雛形を自動生成して必要な調整だけ加える方が、ヒューマンエラー（'unsafe-inline' の付け忘れ消し忘れ、nonceの固定化、HSTSの取り違え）を構造的に減らせます。

私が公開している OSS のセキュリティツールキット Aegis は、この水平統制のランタイム強化——ヘッダー/CSP・レート制限・CSRF・型付きenv境界の導入——を1コマンドで雛形化します。

# ランタイム強化の雛形を導入（ヘッダー/CSP・レート制限・CSRF・型付きenv境界）
npx @aegiskit/cli init

過大に主張するつもりはありません。init が生成するのは出発点となる設定であって、§6 で見たサードパーティ調整や、ページごとの動的化トレードオフは、結局あなたのアプリの構成に合わせて詰める必要があります。それでも、白紙から書いて落とし穴を踏むより、検証済みの雛形から始める方が安全で速い。これは Aegis の scan（SASTで現状の穴を可視化）と組み合わせると、「今ある穴を見える化 → ランタイム強化を導入」という流れになります。

8. 最大の注意 — CSPはXSS対策の補完であって、出力設計の代わりではない

ここが、本記事で最も強調したい点です。CSP を入れても、XSS が「なくなる」わけではありません。

CSP は多層防御の一層、いわば「XSS が混入してしまった場合に、被害を縮小する最後の砦」です。攻撃者のスクリプトの実行を妨げる確率は上げますが、そもそも汚染データを安全に出力する責任は、依然としてアプリのコード側にあります。例えば次のコードは、CSP が厳格でも問題が残ります。

// CSP があっても安全設計の代わりにはならない例
// 汚染データをそのまま HTML として注入している
<div dangerouslySetInnerHTML={{ __html: userSuppliedHtml }} />

'unsafe-inline' を許していない nonce 方式 CSP は、ここに注入された <script> の実行を多くの場合は妨げます。しかし、CSP のバイパス手法は研究され続けており、base-uri の不備、許可した古いライブラリ経由の実行、'strict-dynamic' の連鎖の悪用など、設定の穴次第で抜けられます。さらに、スクリプト実行を伴わない攻撃（リンクの差し替え、フォームの乗っ取り、コンテンツ改ざんによるフィッシング）は CSP の script-src では止まりません。

正しい順序はこうです。まず出力を設計で安全にする（汚染データをサニタイズ/エスケープし、危険なシンクに素通ししない）。その上で、CSP を「それでも何か漏れたとき」の保険として重ねる。順序を逆にして「CSP があるからサニタイズは適当でいい」と考えるのが、最も危険な誤解です。

XSS そのものの防ぎ方——dangerouslySetInnerHTML の安全な扱い、DOM XSS、汚染データのサニタイズ——はNext.jsのXSS/DOM XSS対策で別途詳説しています。CSP はその記事の対策を置き換えるものではなく、補完するものです。これは OWASP のOWASP Top 10が一貫して示す多層防御の思想そのものです。

9. ヘッダーと並ぶ、他の水平統制

ヘッダー/CSP は水平統制の一部にすぎません。同じ「設定で一律に固める」発想で、middleware や境界に寄せるべき仲間がいます。本記事の範囲外なので、それぞれ専門記事に委ねます。

CSRF / Origin 検証 — Server Actions や POST ルートのような状態変更経路は、SameSite Cookie に加えて Origin を検証して二段で守ります。詳細はNext.jsのCSRF/Origin保護へ。
秘密情報の衛生 — NEXT_PUBLIC_ 接頭辞の誤用で秘密がクライアントバンドルに混入する事故は、ヘッダーでは防げません。env境界の設計はNext.jsの環境変数・秘密情報の漏洩防止で扱います。
レート制限・入力検証 — これらも水平統制で、アプリケーションセキュリティ全体像に地図としてまとめてあります。

重要なのは、**これらはすべて「自動化できる層」**だということです。設定とライブラリで肩代わりでき、CIに番をさせられます。問題は、その先にある認可やテナント分離といった「設計でしか守れない垂直リスク」で、そこは次節の監査領域に移ります。

10. 本番前チェックリスト

外注でもAI製でも、本番投入の前にこれだけは確認してください。

CSP に 'unsafe-inline'（script）を入れていない。入れるなら nonce/hash を使う
nonce がリクエストごとに変わる（curl -I を2回叩いて値が違うこと）
自前のインラインスクリプト/<Script> すべてに nonce を付与している
Report-Only で実トラフィックの違反を観測してから強制へ昇格した
Strict-Transport-Security を本番(HTTPS)でのみ付与している（preload の不可逆性も理解の上で）
X-Content-Type-Options: nosniff / Referrer-Policy / frame-ancestors（+ X-Frame-Options）/ Permissions-Policy を付与している
matcher で静的アセットを除外し、不要なヘッダー付与を避けている
CSP を「サニタイズの代わり」にしていない。汚染データの出力は設計側で安全にしている
middleware が Edge ランタイム互換（Node専用APIに依存していない）

発注者の視点で効くのは、**「CSPに 'unsafe-inline' は入っていますか？」「nonceはリクエストごとに変わりますか？」「Report-Onlyで段階導入しましたか？」**の3問です。良い開発者は即答できます。

11. どこまで自動化、どこから監査か

最後に正直に線を引きます。

セキュリティヘッダーと CSP は、水平統制として大半を機械的に固められます。 middleware 1枚に集約し、雛形から始め、Report-Only で段階導入する——この型さえ守れば、人間が毎回ゼロから考える必要はありません。まずは Aegis（無料OSS、npx @aegiskit/cli init でランタイム強化、scan で現状把握）で雛形を入れるのが、最もコスパの良い第一歩です。

一方、CSP は XSS の被害を縮小しても、認可・テナント分離・業務ロジックといった「正規リクエストとして現れる垂直リスク」には一切効きません。 これらはヘッダーでもWAFでも構造的に防げず、あなたのデータモデルを理解した人間にしか設計・検証できません。ここで「ヘッダーを入れたから安全」と考えるのが、最も危険な油断です。ヘッダーは入口の保険であって、認可の正しさを証明するものではありません。

だからこそ線引きが要ります。どこまで自分で固め、どこから専門家のレビューが要るか——その判断や、既存アプリの認可・RLS・出力設計を含むレビューが必要なら、セキュリティ監査で承ります。私自身、サーバーレス決済プラットフォームの案件で、決済信頼性レイヤーを含むアプリ層の堅牢化を実運用で設計・検証してきました。

よくある質問（FAQ）

Q. next.config.js の headers() ではダメですか？ A. 値が固定のヘッダー（HSTS、nosniff、Referrer-Policy 等）なら headers() でも付けられます。ただし nonce はリクエストごとに変わるため next.config.js では表現できません。CSPを nonce 方式で運用するなら middleware が必須です。固定ヘッダーも含めて middleware に集約した方が、関所が1つになり管理しやすくなります。

Q. nonce と hash、どちらを使うべきですか？ A. 自前のインラインスクリプトが動的に変わる、または複数ある場合は nonce が扱いやすい。インラインスクリプトが皆無、または固定で、ページを完全静的にキャッシュしたい場合は hash（'sha256-…'） が向きます。hash なら headers() を呼ばずに済み、静的配信を維持できます。アプリの大半は nonce で問題ありませんが、CDNフルキャッシュ最優先のページだけ hash、という使い分けも有効です。

Q. CSPを入れれば XSS は防げますか？ A. 防げません。CSP は XSS が混入した場合の被害を縮小する最後の砦であって、出力の安全設計（サニタイズ/エスケープ）の代わりにはなりません。CSP のバイパス手法も存在します。まず出力を設計で安全にし、その上で CSP を保険として重ねる——この順序が必須です。詳細はXSS対策の記事を参照してください。

Q. Report-Only のまま運用し続けてもいいですか？ A. よくありません。Report-Only は何もブロックしません。違反を観測する移行期間のためのモードであり、ここで止まると「CSPがあるように見えて、実際には何も守っていない」状態になります。違反が枯れたら必ず Content-Security-Policy（強制）へ昇格させてください。

Q. 個人開発や小規模でもここまでやるべきですか？ A. ヘッダーは水平統制で、導入コストが極めて低い（middleware 1枚）のに、塞げる攻撃面は広い。費用対効果が最も高い対策の一つです。最低でも nosniff・Referrer-Policy・frame-ancestors・HSTS の4つと、'unsafe-inline' を使わない CSP は、規模に関わらず入れる価値があります。

まとめ — 1枚に集約し、保険として重ねる

要点を整理します。

セキュリティヘッダーは アプリ横断で一律に効く「水平統制」。middleware.ts 1枚に集約して自動化するのが正解。
各ヘッダーは別々の脅威を1つずつ塞ぐ（CSP→XSS被害縮小、HSTS→MITM、nosniff→MIMEスニッフィング、frame-ancestors→クリックジャッキング、Referrer-Policy→URL漏洩、Permissions-Policy→機能濫用）。1個で全部は守れない。
nonce 方式 CSP だけはリクエストごとの生成が必須で、静的設定では実現できない。middleware で生成し、ヘッダーとアプリの両方へ受け渡す。
本番投入は Report-Only で観測 → 修正 → 強制へ昇格。いきなり強制すると壊れる。
これらは雛形化でき（npx @aegiskit/cli init）、自動化できる層。ただし CSP は XSS の最後の砦であって、出力サニタイズ＝設計の代わりにはならない。
ヘッダーで塞げない認可・テナント分離は垂直リスクで、設計と監査の領域。

AIで速く作ること自体は正しい。速く作ったものを、漏らさず安全に固める——その水平統制の自動化や、既存アプリのヘッダー/CSP・出力設計のレビューが必要であれば、お気軽にご相談ください。

Next.jsのセキュリティヘッダーとCSP(nonce) — middleware 1枚で多層防御を自動化する

1. なぜヘッダーは「自動化できる水平統制」なのか

2. 主要セキュリティヘッダーと、各々が塞ぐ脅威

3. CSPの基礎 — default-src / script-src と、なぜ `'unsafe-inline'` が危険か

なぜ `'unsafe-inline'` が危険か

正解: nonce + strict-dynamic

4. 実装 — middleware 1枚でnonceを生成し、ヘッダーとアプリへ受け渡す

4-1. middleware: nonce生成とヘッダー付与

4-2. アプリ側: nonceを読んで `<script>` に付ける

4-3. 動作確認

5. Report-Only で段階導入する — いきなり強制しない

6. 正直な落とし穴 — Next.js特有の現実

7. これは「水平統制」— Aegisのinitで自動化できる

8. 最大の注意 — CSPはXSS対策の補完であって、出力設計の代わりではない

9. ヘッダーと並ぶ、他の水平統制

10. 本番前チェックリスト

11. どこまで自動化、どこから監査か

よくある質問（FAQ）

まとめ — 1枚に集約し、保険として重ねる

参考資料

Next.js × Supabase アプリケーションセキュリティ完全ガイド — 脆弱性の検出と多層防御で、認可・RLSを守る

Next.js Server ActionsのCSRF / Origin対策 — 何が標準で守られ、何を足すべきか

Next.jsの環境変数と秘密漏洩対策 — NEXT_PUBLIC_ の罠と、型付き env 境界

Next.jsのオープンリダイレクト対策 — 認証 callbackUrl / redirect() を検証する

1. なぜヘッダーは「自動化できる水平統制」なのか

2. 主要セキュリティヘッダーと、各々が塞ぐ脅威

3. CSPの基礎 — default-src / script-src と、なぜ 'unsafe-inline' が危険か

なぜ 'unsafe-inline' が危険か

正解: nonce + strict-dynamic

4. 実装 — middleware 1枚でnonceを生成し、ヘッダーとアプリへ受け渡す

4-1. middleware: nonce生成とヘッダー付与

4-2. アプリ側: nonceを読んで <script> に付ける

4-3. 動作確認

5. Report-Only で段階導入する — いきなり強制しない

6. 正直な落とし穴 — Next.js特有の現実

7. これは「水平統制」— Aegisのinitで自動化できる

8. 最大の注意 — CSPはXSS対策の補完であって、出力設計の代わりではない

9. ヘッダーと並ぶ、他の水平統制

10. 本番前チェックリスト

11. どこまで自動化、どこから監査か

よくある質問（FAQ）

まとめ — 1枚に集約し、保険として重ねる

参考資料

関連記事

Next.js × Supabase アプリケーションセキュリティ完全ガイド — 脆弱性の検出と多層防御で、認可・RLSを守る

Next.js Server ActionsのCSRF / Origin対策 — 何が標準で守られ、何を足すべきか

Next.jsの環境変数と秘密漏洩対策 — NEXT_PUBLIC_ の罠と、型付き env 境界

Next.jsのオープンリダイレクト対策 — 認証 callbackUrl / redirect() を検証する

3. CSPの基礎 — default-src / script-src と、なぜ `'unsafe-inline'` が危険か

なぜ `'unsafe-inline'` が危険か

4-2. アプリ側: nonceを読んで `<script>` に付ける