content security policy and google tag manager

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は、ブラウザに対して「このサイトが読み込み・通信してよい相手はここだけ」と宣言する仕組みです。許可していないスクリプトの読み込みや外部への送信を、ブラウザ側がブロックします。 ...

2026年8月17日 · 読了時間: 5分 · 福士宗介
XSS の4つの侵入経路と多層防御モデル

Web アプリの XSS はどこから入るか — 4 つの侵入経路と多層防御モデル

「Reactは自動エスケープしてくれるからXSSは古い話」——そう思っていないでしょうか。 実際には、ReactやNext.jsが標準で塞いでくれる経路は XSS の侵入口の一部 にすぎません。dangerouslySetInnerHTML、依存パッケージの汚染、悪意ある拡張機能。これらはReactの自動エスケープを そもそも経由しません。 この記事では、現代のWebアプリでXSSが侵入してくる 4 つの経路 を整理し、それぞれに対する 多層防御モデル をマトリクス化します。最後に、認証トークンの保存設計(better-authのAccess Tokenを例に)を取り上げて、「攻撃経路 × 防御層」で判断する具体例を示します。 この記事を書いたきっかけ 3サイトのフロントエンドを並行開発する中で、リリース運用フェーズへの移行に合わせて認証セキュリティ設計を見直しました。実装を読み込むと、「Access Tokenに5分のTTLを設定しているから安全」という直感は持続的XSSのケースでは成り立たないと気づきました。第1号「NextAuth v5 から better-auth へ!逆引き移行チートシート」で扱った認証基盤の続編として、運用フェーズで考えるべき多層防御の整理を共有します。 先に結論:攻撃経路 × 防御層のマトリクス 詳細は本文で展開します。結論は次のマトリクスに集約されます。 Stored Reflected DOM-based サプライチェーン 拡張機能 CSP ◎ ◎ ◯ △ × レート制限 △ △ △ × × トークン隔離 △ △ △ × × 異常検知 △ △ △ △ △ 読み取り: CSP が最も広く効く根本対策。ただしサプライチェーンと拡張機能には限界がある 認証トークン隔離(BFF化)の効果は限定的で、AT 値漏洩経路は塞ぐが、API 不正コール経路は塞げない 単独の銀の弾丸はなく、組み合わせる前提で設計する なぜこのマトリクスになるのか、なぜトークン隔離だけでは不十分なのかを、以下で順に解説します。 この記事で得られること XSSの 4 つの侵入経路(Stored / Reflected / DOM-based / サプライチェーン・拡張機能)の整理 「持続的 XSS」という概念と、それが短命トークンを無効化する仕組み CSP / レート制限 / 認証トークン隔離 / エラー監視 の4つの守備範囲を比較した防御マトリクス 認証トークンを JS から隠す設計 が「何を防げて、何を防げないか」 単一の銀の弾丸ではなく、多層で組み合わせる ための判断軸 動作確認環境 種別 バージョン OS macOS 15.x Node.js 24.x パッケージマネージャー pnpm 10.x Next.js 16.x(App Router) React 19.x better-auth 1.x 1. なぜ XSS が今も現役なのか XSS(Cross-Site Scripting)は2000年代から続く古典的な脆弱性です。ReactやVueのような現代のフレームワークは、テンプレート内の変数を自動的にエスケープしてくれます。 ...

2026年6月3日 · 読了時間: 7分 · 福士宗介