
CSP は enforce か Report-Only か — GTM を使うサイトで変わる判断基準
セキュリティ診断でフロントエンドの残課題が「CSP未導入」の1点に絞られたので、3つのNext.jsサイトにContent-Security-Policy(CSP)を入れました。 ところが、同じ構成のはずなのに 管理系の2サイトは enforce で即入ったのに、Google Tag Manager(GTM)を使うユーザー向けサイトだけは enforce にできませんでした。「未リリースだから最初からenforceでいい」と考えていたのが、GTMの前で崩れたわけです。 この記事では、GTMを使うサイトがCSPを厳格化しづらい理由を、Google公式ドキュメントで裏取りします。そのうえで、enforce / Report-Only / 2ヘッダ併用の使い分けと、Next.js App Routerでの実装・検証方法をまとめます。 この記事で得られること CSPが 何を防ぎ・何を防がないか(XSSの"被害"を減らす多層防御という位置づけ) Next.js App RouterでCSPを付与する 最小実装(enforce / Report-Onlyの切り替え) GTMを使うサイトで enforce が難しい理由(nonceでも救えない領域がある) enforce / Report-Only / 2ヘッダ併用 の判断基準 enforceする場合の Google 公式推奨(nonce + strict-dynamic) とGA4の許可ドメイン、そして nonce のレンダリングコスト connect-src など 壊しやすいディレクティブと、E2Eを使った回帰の切り分け 動作確認環境 種別 バージョン OS macOS 15.x(開発) Node.js 24.x パッケージマネージャー pnpm 9.x Next.js 15.x / 16.x(App Router) React 19.x ホスティング Node ランタイム(headers() で付与) CSP とは何で、何を守るのか CSPは、ブラウザに対して「このサイトが読み込み・通信してよい相手はここだけ」と宣言する仕組みです。許可していないスクリプトの読み込みや外部への送信を、ブラウザ側がブロックします。 ...
