検証した主張
「推奨のCSP文字列を全サイトへコピーすれば、動作確認なしに安全性だけが上がる。」
発見元は調査の入口であり、判定の根拠には使用していません。Cloudflareで付けられるが、内容はサイト固有
Response Header Transformを使うと、Cloudflareからの応答へヘッダーを追加・変更できます。CSPは読み込めるスクリプト、画像、フレームなどを指定します。広告、解析、埋め込み、決済など外部資源があるサイトで一律の値を貼ると機能停止につながります。
最初に既存のHTMLとNetworkを調べ、必要なオリジンとインラインスクリプトの扱いを一覧にします。
段階的に導入する
報告のみのモードやテスト環境で違反を観測し、表示、フォーム、検索、スマホ操作を確認してから強制適用を検討します。ヘッダーを見ただけでXSS対策が完成したとは扱いません。
アプリ側のエスケープ、依存ライブラリの更新、権限管理も必要です。
キャッシュ設定との混同に注意
レスポンスヘッダー変更はキャッシュ判定の後に適用される場合があります。Cache-Controlを後から追加しても、Cloudflareエッジの保存判定を遡って変更できるわけではありません。
個人データのキャッシュ対策はオリジン応答とCache Rulesの両方で確認します。
検証条件・対象環境
| 対象プラン | 製品・契約プランで機能と表示範囲が異なる |
|---|---|
| 地域 | 提供地域・利用環境で表示や条件が異なる場合あり |
| 利用面 | Cloudflare Dashboard / Webサイト・API |
| 提供状態 | 2026年9月22日時点の公式公開資料。ダッシュボードの名称・契約条件は変更され得る |
| 実機確認 | Cloudflare公式資料で機能と制限を照合しました。個別のサイト・アカウントで設定変更や攻撃の再現はしていません。 |
| 次回見直し | 2026.10.22 |
よくある質問
CSPを設定すればサイトのXSS対策は完了しますか？
Cloudflareのレスポンスヘッダー変更ルールでCSPなどを追加できます。ただしサイトの実際の外部資源を調べずに厳しいポリシーを入れると表示や機能が壊れます。
更新履歴
初回公開
公式資料を確認し、固有の利用情報を含まない一般的な手順・注意点として整理。
訂正
実機検証は未実施のため、根拠レベルを公開基準に合わせてAからBに訂正。
情報源
一次情報と発見元を区別し、各ページの公開日と確認日を記録しています。
- Response header modification
レスポンスヘッダー変更と適用順序。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Cache Rules settings
Edge TTLがオリジン指示を上書きする条件。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Always Use HTTPS
HTTPからHTTPSへの転送。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22