NoteStack

This page is a beginner-friendly note about how to observe CSP reports in Report-Only mode, focusing on “overall trends” (not per-page debugging) and how to avoid panicking over Google Ads related domains.

「え、広告出してないのに？」CSPログを“全体まとめ”で観測する（Report-Only運用の判断軸）

CSPログを見て「これ、攻撃…？」と焦ったときに、まず“全体まとめ”で落ち着いて判断するための見方だけまとめます。

まず何が引っかかったか：広告を出してない /dmm/ で Google広告が見える

私は /dmm/ ページには Google広告を表示していません。

でも CSP の集計結果を見ると、pagead2.googlesyndication.com や doubleclick.net が上位に出てきて、「え、どこから？」となりました。

ここで一旦、前提をそろえる
  • 今は Report-Only（観測だけ）
  • サイトのほとんどのページでは Google広告を出している（削除予定はない）
  • /dmm/ は 広告なし（基準ページとして使える）
このメモでやりたいこと（先に言い切る）

ログを「減らす」よりも、ログを“怖がりすぎない”ための判断を作るのが目的です。

結論：学習フェーズは「全体まとめ」で傾向だけ見れば十分

最初はページ別に原因を追いたくなりますが、私はまず全体まとめに寄せました。

いまの方針（このチャットで決めたこと）
  • まずは 学習・観測目的でログだけ取る
  • 確認頻度は 2〜3週間に1回くらいで十分
  • 保存期間は未決（ディスクに余裕があるので 急いで決めない）
大事な気持ちの切り替え

CSPレポートは「サーバーが攻撃されたログ」ではなく、ブラウザが“この読み込みはCSP的にNG扱いになったよ”と報告してくるログです。

Report-Only なら、まずは 何が起きているかを知るだけでOKです。

まず見る3つ：directive / blocked_uri / document_uri

私が混乱したのは、「どこを見れば判断が進むか」が曖昧だったことでした。

1) directive（どういう種類の違反が多いか）

最初は件数を見て焦りますが、私は“種類が増えていないか”だけ見ます。

  • img-src：画像
  • script-src-elem：外部JS（<script src=...>）
  • connect-src：通信（fetch / XHR / sendBeacon / WebSocket）
  • frame-src：iframe

この4つで安定しているなら、「毎日のノイズで揺れてるだけ」になりやすいです。

2) blocked_uri（何がNG扱いになったか）

ここは“常連”と“新顔”の見分けがすべてです。

  • 常連：Google広告/解析系（出続けるなら仕様として扱う）
  • 新顔：見覚えのない外部ドメイン（いったんメモする）

私のログでは blocked_uri: "inline" も目立ちました。これは「URLがブロックされた」というより、インラインの script / style（または注入）が引っかかった、という合図です。

3) document_uri（どのページで起きてるか）

ここは「ページ別に直す」ためではなく、“どこがアクセス集中点か”を見る目的で使います。

上位に来るページは、単にアクセスが多いだけでも増えます。

/dmm/ を基準ページにする：ここで出たものは「ノイズ辞書」になる

/dmm/ は広告を出していないので、ここで Google広告系が出ると焦りやすいです。

でも逆に言うと、/dmm/ は 「広告なし・自分のコード中心」になりやすいので、ここで出たものは「外部要因」の可能性が高いです。

私が「まずノイズ扱い」にしたもの
  • 広告/計測系ドメイン（Google系が中心）
  • blocked_uri: "inline"（拡張が注入している可能性も含む）
ここでの注意（誤解しやすい）

/dmm/ に広告コードが無いなら、ログに広告が出ても「サーバーが改ざんされた」とは直結しません。

ブラウザ拡張・閲覧環境・広告SDKの副作用など、“クライアント側の事情”が混ざります。

2〜3週間に1回の確認で見ること：3点だけに絞る

私は「毎日見る」ほどのログ量でもないので、不定期に近い運用にしました。

チェック1：blocked_uri に新顔が増えた？

前回と比べて見覚えのない外部ドメインが増えたら、そこで初めて深掘り候補にします。

逆に、上位が固定なら「観測は順調」です。

チェック2：directive の“種類”が増えた？

件数は広告やアクセス数で揺れますが、種類が増えるのは構成変更や埋め込み増加のサインになりやすいです。

チェック3：document_uri の上位が急に入れ替わった？

上位が急に変わった場合、ページの追加・改修・外部埋め込みの影響を疑えます。

私は確認した日だけ、どこかに「新顔なし / 変化なし」と1行メモしておくと、後で判断が楽になりました。

保存期間を急いで決めない：ディスクに余裕があるなら「連続性」を優先

保存期間はまだ決めていません。

いま決めない理由

学習フェーズで一番価値があるのは、「2週間〜1か月で何が変わったか」の比較です。

早く削ると、比較の材料が消えてしまいます。

私が“検討を始めるスイッチ”にしたもの
  • blocked_uri の顔ぶれが 2〜3週間ほぼ固定になった
  • 新規ドメインが月に数個程度に落ちた
  • 「enforce を考えてもよさそう」と直感的に思えた

この状態になってから保存期間を決めれば、遅くないと感じました。

将来 enforce（強制）にするか？：今は「判断材料を集める」だけ

私はまだ enforce に切り替えません。

Report-Only のまま観測する理由
  • 広告・解析・外部JSが止まると、原因切り分けが一気に難しくなる
  • まず「何が常連か」「何が変動か」を説明できる状態にしたい
enforce を検討できる状態（目安）
  • 広告ページで blocked_uri の上位が安定している
  • 新顔のドメインが“たまに”程度になっている
  • /dmm/（基準ページ）と広告ページの差分を説明できる

ここまで来たら、次に「CSPを1本で統一するか、ページで分けるか」を考えればよい、という順番にしました。

よくある質問（FAQ）

Q. /dmm/ に広告を入れてないのに、なぜ広告ドメインがログに出る？

A. ブラウザ拡張・閲覧環境・計測や広告SDKの副作用など、クライアント側の要因が混ざることがあります。/dmm/ のような広告なしページは、むしろ「ノイズ辞書」を作る基準として使えます。

Q. Google広告系の blocked_uri が多いのは危険？

A. 広告を出しているページが多いなら、Report-Only の観測としては“多いのが普通”です。件数ではなく、「常連か / 新顔か」「種類が増えたか」を見たほうが判断しやすいです。

Q. どれくらいの頻度で見ればいい？

A. 私はログ総量が少ないので 2〜3週間に1回にしました。CSPログは日次で揺れるので、見すぎるとノイズで疲れやすいです。

Q. 保存期間は何日が正解？

A. 学習フェーズでは「連続性」が価値なので、ディスクに余裕があるなら急いで決めなくて大丈夫です。blocked_uri の顔ぶれが安定してから決めると失敗しにくいです。

Q. いつ enforce に切り替える？

A. 広告ページの blocked_uri が安定し、新顔が減り、/dmm/ との違いを説明できるようになってから検討します。いきなり enforce にすると、広告や外部JSが止まって混乱しやすいです。