CSP を読む — 本物のポリシーを、指令ごとに

default-src は、他の -src 指令が無いときの既定値です。‘self’ は「同一オリジンだけ」。つまり、明示的に緩めない限り、スクリプトも画像も通信先もすべて自分のオリジンに限るのが土台。ここから、必要なものだけを個別の -src で足していきます。「既定は最も厳しく、例外だけ開ける」——認可の deny-by-default と同じ発想です。

script-src ‘self’ https://static.cloudflareinsights.com ‘sha256-…’
読み解くと——スクリプトの実行を許すのは、①同一オリジンのファイル(‘self’)、②Cloudflare の計測スクリプト1つ、③特定のインラインスクリプト(ハッシュで名指し)だけ。
決定的に大事なのは——‘unsafe-inline’ が無いことです。だから、攻撃者が注入した <script>…</script> や onerror= のようなインラインは、ハッシュに載っていない限り実行されません。これが「XSS の二枚目の壁」の正体。次章で、実際に止まるところを見ます。

このサイトが正当に使うインラインスクリプト(OS 切替の同期スクリプトなど)は、その中身の SHA-256 ハッシュを script-src に列挙して許可しています。build-headers.mjs が、実際に出力された HTML を読んでハッシュを計算する。だから「このハッシュと一字でも違うスクリプト」は通らない——正規のインラインだけを、内容で名指しできる。‘unsafe-inline’(全インライン許可)とは正反対の、狙い撃ちの許可です。静的サイトなので、ビルド時に確定できるこの方式が向いています。

object-src ‘none’ — <object>/<embed>(古いプラグイン)を全面禁止。今どき使わないので、塞いでおく。
base-uri ‘self’ — <base> タグでページ内の相対URLの基準をすり替える攻撃を防ぐ。
form-action ‘self’ — フォームの送信先を自オリジンだけに。注入されたフォームで、入力を外部へ送り出す手口を塞ぐ。
frame-ancestors ‘none’ — このページを誰にも iframe で埋め込ませない(クリックジャッキング防止。前章の X-Frame-Options の新しい版)。

connect-src ‘self’ https://cloudflareinsights.com — fetch / XHR の送信先を、自オリジンと計測先だけに限る。注入されたスクリプトがデータを外部へ持ち出すのを難しくする(万一動いても、送り先が塞がれている)。
style-src ‘self’ ‘sha256-…’ — スタイルも、自オリジンとハッシュ済みのものだけ。
style-src-attr ‘unsafe-inline’ — ここだけ緩い。style=“…” という属性のインラインを許す。理由は明快で、コードを色分けする Shiki が全トークンに style 属性を吐き、進捗バーも JS で幅を書き換えるため。緩んでいるのは style 属性だけで、スクリプトは厳格なまま。属性のスタイルは XSS の実行経路にはならないので、影響は限定的です。

style-src-attr のコメントは build-headers.mjs にそのまま書かれています——「なぜ緩めるか」を理由付きで残す。健全な CSP は、緩い箇所に必ず理由がある。診断で他人の CSP を読むときも、‘unsafe-inline’ や * を見つけたら「なぜここが緩いのか、正当な理由があるのか」を問います。