CSPを設定すると何が防げますか？

主にクロスサイトスクリプティング（XSS）の被害を抑えられます。攻撃者がページにスクリプトを注入できたとしても、CSPが許可していない出どころのスクリプトはブラウザが実行しません。ほかに、`frame-ancestors` でクリックジャッキングを、`form-action` でフォームの送信先すり替えを、`upgrade-insecure-requests` で混在コンテンツを防げます。ただしCSPは二段目の防御であり、入力値のエスケープを省略してよいという意味ではありません。

まず何から設定すればよいですか？

`default-src 'self'` から始めてください。これだけで「同一オリジン以外からは読み込まない」という大枠ができ、個別に指定し忘れた種別も制限されます。そのうえで実際に使っている外部サービスのホストを `script-src` や `img-src` に足していくのが、壊れにくい進め方です。本ツールの「標準」プリセットがこの形になっています。

unsafe-inline は入れてはいけませんか？

`script-src` については避けてください。インラインスクリプトの実行を許すため、XSS対策としてのCSPがほぼ機能しなくなります。`style-src` の `'unsafe-inline'` はリスクが相対的に低く、実務では許容されることが多いですが、それでもスタイル経由の情報漏えい手法は存在します。どうしてもインラインが必要な場合は nonce かハッシュを使ってください。

nonce はどう使いますか？

リクエストごとにランダムな値を生成し、`script-src 'nonce-xxxxx'` のようにヘッダーへ入れ、同じ値を ` ` に付けます。値が一致したスクリプトだけが実行されます。**リクエストごとに必ず変える**ことが前提で、固定値にすると攻撃者が同じ値を使えるため意味がなくなります。本ツールでは `'nonce-{RANDOM}'` というプレースホルダーを出力するので、サーバー側で実際の値に置き換えてください。

metaタグでも設定できますか？

できますが制限があります。`frame-ancestors`・`report-uri`・`sandbox` はmetaタグでは無視されるため、これらを使う場合はHTTPヘッダーで配信する必要があります。また、metaタグはHTMLが解析された時点から有効になるので、それより前に読み込まれるリソースには適用されません。可能な限りHTTPヘッダーを使ってください。

設定したらサイトが壊れました

ブラウザのコンソールに、どのディレクティブがどのURLをブロックしたかが表示されます。その出どころを該当ディレクティブに追加してください。作業中は `Content-Security-Policy-Report-Only` で配信すると、ブロックせずに違反だけを確認できるので安全です。本ツールの出力形式を「Report-Only」に切り替えると、同じ内容をその形式で取得できます。

object-src を 'none' にする理由は？

` ` や ` ` から読み込まれるプラグインコンテンツは、攻撃経路として使われることがあります。現在これらを使っているサイトはほとんどないため、`object-src 'none'` としておけば攻撃面を確実に1つ減らせます。コストがほぼゼロで効果が明確なので、設定しない理由がない項目です。

frame-ancestors と X-Frame-Options の違いは？

どちらも自サイトが他サイトのiframeに埋め込まれるのを防ぐ設定で、クリックジャッキング対策になります。`frame-ancestors` はCSPの一部で、X-Frame-Options の後継です。複数のオリジンを指定できる、ワイルドカードが使えるなど表現力が高く、両方が指定されている場合は `frame-ancestors` が優先されます。新規に設定するなら `frame-ancestors` を使ってください。

report-uri はまだ使えますか？

使えますが、仕様上は `report-to` と `Reporting-Endpoints` ヘッダーへの移行が進んでいます。ただし対応状況はブラウザによって差があるため、現状は両方を指定するか、まず `report-uri` で運用するのが現実的です。レポートを受け取るエンドポイントは自前で用意するか、外部の収集サービスを使います。

生成した設定は外部に送信されますか？

いいえ、すべてブラウザ内で組み立てています。社内システムのホスト名、未公開のサブドメイン、使用している外部サービスの構成など、サイトの内部情報が読み取れる内容を含んでいても、外部サーバーに送信されることはありません。

CSP生成｜Content-Security-Policyをフォームで作成

// CSP ジェネレーターの機能と特徴

CSPとは

Content-Security-Policy は、ページが読み込んでよいリソースの出どころをブラウザに指示するレスポンスヘッダーです。許可していない場所からのスクリプトやスタイルはブラウザ側でブロックされるため、**仮にXSSの脆弱性が残っていても、攻撃スクリプトの実行を止められる可能性があります**。入力値のエスケープが「侵入させない」対策だとすれば、CSPは「侵入されても動かさない」二段目の防御です。ヘッダーの状態を確認したい場合は HTTPヘッダ解析が使えます。

default-src と各 *-src の関係

`default-src` は、個別に指定していないリソース種別すべての既定値になります。`script-src` を書けばスクリプトはそちらが優先され、書かなければ `default-src` が適用されます。つまり **`default-src 'self'` を置いておけば、書き忘れたディレクティブも自動的に制限される**ため、まずこれを設定するのが定石です。逆に `default-src` がないと、指定し忘れた種別は無制限になります。本ツールは `default-src` が無効なとき警告します。

unsafe-inline を入れると何が無意味になるか

`script-src` に `'unsafe-inline'` を入れると、HTMLに直接書かれた `<script>` や `onclick=` 属性の実行が許可されます。XSSの多くはまさにこの形で注入されるため、**CSPのXSS対策としての効果はほぼ失われます**。既存のインラインスクリプトを動かすために付けたくなりますが、本来は nonce かハッシュに移行すべきです。なお CSP Level 2 以降のブラウザは、nonce やハッシュが指定されている場合に `'unsafe-inline'` を無視します。

Report-Only で試してから適用する

CSPをいきなり本適用すると、見落としていた外部スクリプトが止まってサイトが壊れることがあります。`Content-Security-Policy-Report-Only` ヘッダーで配信すると、**ブロックはせず違反だけをレポートします**。まずこれで数日運用し、報告された違反を見ながらポリシーを調整してから本適用するのが安全な手順です。本ツールは同じ内容を Report-Only 版としても出力します。

よくある構成のプリセットを用意

Google Analytics・Google AdSense・Google Fonts を使うサイト向けのプリセットを用意しています。これらは必要なホストが複数あり、手書きだと漏れやすい代表例です。ほかに「厳格」（最小限の許可のみ）と「標準」も選べます。プリセットを読み込んでから自サイトのホストを足すのが、ゼロから書くより早く確実です。生成した設定の検証には HTTPヘッダ解析、CORS の設定には CORS設定ジェネレーターを併用できます。

// CSP ジェネレーターに関するよくある質問

CSPを設定すると何が防げますか？: 主にクロスサイトスクリプティング（XSS）の被害を抑えられます。攻撃者がページにスクリプトを注入できたとしても、CSPが許可していない出どころのスクリプトはブラウザが実行しません。ほかに、`frame-ancestors` でクリックジャッキングを、`form-action` でフォームの送信先すり替えを、`upgrade-insecure-requests` で混在コンテンツを防げます。ただしCSPは二段目の防御であり、入力値のエスケープを省略してよいという意味ではありません。
まず何から設定すればよいですか？: `default-src 'self'` から始めてください。これだけで「同一オリジン以外からは読み込まない」という大枠ができ、個別に指定し忘れた種別も制限されます。そのうえで実際に使っている外部サービスのホストを `script-src` や `img-src` に足していくのが、壊れにくい進め方です。本ツールの「標準」プリセットがこの形になっています。
unsafe-inline は入れてはいけませんか？: `script-src` については避けてください。インラインスクリプトの実行を許すため、XSS対策としてのCSPがほぼ機能しなくなります。`style-src` の `'unsafe-inline'` はリスクが相対的に低く、実務では許容されることが多いですが、それでもスタイル経由の情報漏えい手法は存在します。どうしてもインラインが必要な場合は nonce かハッシュを使ってください。
nonce はどう使いますか？: リクエストごとにランダムな値を生成し、`script-src 'nonce-xxxxx'` のようにヘッダーへ入れ、同じ値を `<script nonce="xxxxx">` に付けます。値が一致したスクリプトだけが実行されます。**リクエストごとに必ず変える**ことが前提で、固定値にすると攻撃者が同じ値を使えるため意味がなくなります。本ツールでは `'nonce-{RANDOM}'` というプレースホルダーを出力するので、サーバー側で実際の値に置き換えてください。
metaタグでも設定できますか？: できますが制限があります。`frame-ancestors`・`report-uri`・`sandbox` はmetaタグでは無視されるため、これらを使う場合はHTTPヘッダーで配信する必要があります。また、metaタグはHTMLが解析された時点から有効になるので、それより前に読み込まれるリソースには適用されません。可能な限りHTTPヘッダーを使ってください。
設定したらサイトが壊れました: ブラウザのコンソールに、どのディレクティブがどのURLをブロックしたかが表示されます。その出どころを該当ディレクティブに追加してください。作業中は `Content-Security-Policy-Report-Only` で配信すると、ブロックせずに違反だけを確認できるので安全です。本ツールの出力形式を「Report-Only」に切り替えると、同じ内容をその形式で取得できます。
object-src を 'none' にする理由は？: `<object>` や `<embed>` から読み込まれるプラグインコンテンツは、攻撃経路として使われることがあります。現在これらを使っているサイトはほとんどないため、`object-src 'none'` としておけば攻撃面を確実に1つ減らせます。コストがほぼゼロで効果が明確なので、設定しない理由がない項目です。
frame-ancestors と X-Frame-Options の違いは？: どちらも自サイトが他サイトのiframeに埋め込まれるのを防ぐ設定で、クリックジャッキング対策になります。`frame-ancestors` はCSPの一部で、X-Frame-Options の後継です。複数のオリジンを指定できる、ワイルドカードが使えるなど表現力が高く、両方が指定されている場合は `frame-ancestors` が優先されます。新規に設定するなら `frame-ancestors` を使ってください。
report-uri はまだ使えますか？: 使えますが、仕様上は `report-to` と `Reporting-Endpoints` ヘッダーへの移行が進んでいます。ただし対応状況はブラウザによって差があるため、現状は両方を指定するか、まず `report-uri` で運用するのが現実的です。レポートを受け取るエンドポイントは自前で用意するか、外部の収集サービスを使います。
生成した設定は外部に送信されますか？: いいえ、すべてブラウザ内で組み立てています。社内システムのホスト名、未公開のサブドメイン、使用している外部サービスの構成など、サイトの内部情報が読み取れる内容を含んでいても、外部サーバーに送信されることはありません。

// CSP ジェネレーターの使い方

プリセットを選ぶ

「厳格」「標準」や、Google Analytics・AdSense・Google Fonts のプリセットから近いものを選びます。ゼロから組むより早く、必要なホストの書き漏らしも防げます。
ディレクティブと許可する出どころを指定

各ディレクティブを有効にし、`'self'` などのキーワードを選んだうえで、自サイトが使う外部ホストを入力欄に空白区切りで追加します。`'none'` は他の指定と併用できないため、選ぶと自動的に他が外れます。
警告を確認して出力をコピー

`unsafe-inline` の使用や `default-src` の未設定は警告として表示されます。内容を確認したら出力形式を選んでコピーしてください。初回適用時は「Report-Only」で配信し、違反レポートを見てから本適用するのが安全です。