Content-Security-Policy ビルダー
ディレクティブごとのフォームから Content-Security-Policy ヘッダーを構成する。各ディレクティブはスペース区切りのソースリスト（'self'、'none'、'unsafe-inline' などのキーワード、スキーム/ホストソース）を受け入れる。unsafe-inline、unsafe-eval、ワイルドカードを含むポリシーにフラグを立て、空のディレクティブを出力から省略し、レスポンスヘッダー形式と同等の <meta> タグの両方を出力する。新しいポリシーを本番にロールアウトしている間は report-only モードに切り替え。
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'">
空のディレクティブは default-src にフォールバックする。最初に default-src 'self' を設定し、その後個別のソースを狭める。
使い方
- プリセットから始める（Strict はすべて 'self' にロック、Relaxed はインライン + ワイルドカードを許可、API-only はナビゲーションをブロック）。
- 各ディレクティブを編集 — フィールドを空にするとドロップ。
- 新しいポリシーをリリースするときは report-only をオン：違反は報告されるがブロックされない。
よくある質問
- ヘッダーか <meta> タグか — どちらを使うべき？
- HTTP ヘッダーが推奨される。<meta> 形式はレスポンスヘッダーを編集できないとき（静的ホストなど）に便利だが、frame-ancestors や report-uri/report-to を定義できないため、厳密に劣る。
- なぜワイルドカードが警告？
- ソースリストの * はあらゆる URL にマッチし、ポリシーを完全に無効化する。代わりに特定のオリジンに固定するか、'self' を使う — 本当にサードパーティスクリプトが必要な場合は明示的にリストする。
関連ツール
CSP ハッシュジェネレーター
Content-Security-Policy でホワイトリストする必要のあるインライン <script> または <style> ブロックの sha256 / sha384 / sha512 base64 ハッシュを計算。
HSTS ヘッダービルダー
Strict-Transport-Security ヘッダーを構成 — max-age、includeSubDomains、preload — プリロードリスト適格性のライブチェック付き。
SPF レコードビルダー
メカニズム・IP・include から SPF TXT レコードを構成 — ライブ DNS ルックアップカウンタと警告付き。
Permissions-Policy ヘッダービルダー
`Permissions-Policy` レスポンスヘッダーをビルド — カメラ、マイク、ジオロケーション、ペイメント、フルスクリーン、その他 20 以上のブラウザ機能をオリジン許可リストでトグル。
Referrer-Policy ヘッダービルダー
Referrer-Policy 値を選んで、送信リクエストが `Referer` ヘッダーに正確に何を送るかを見る — 同一オリジン、クロスオリジン HTTPS、HTTPS→HTTP ダウングレード。
/.well-known/* URI リファレンス
IANA登録のwell-known URIの検索可能カタログ — `security.txt`·`openid-configuration`·`apple-app-site-association`·`acme-challenge` 他30+、RFCリファレンス·使用例付き。