【テクニカル・上級編】CSP報告用エンドポイント(report-uri/report-to)の構築 – アプリケーションセキュリティ & 安全な開発防御ガイド

盲点としてのCSPレポート：攻撃の「予兆」を解読するアーキテクチャ設計

多くのセキュリティエンジニアが「CSPはXSSを防ぐための静的なガードレールである」と誤解している。だが、現場で泥をすすっている我々からすれば、CSPは単なる防御壁ではなく、「攻撃者がシステムを偵察している足跡を可視化するテレメトリ」だ。

今回は、単に report-uri を設定して終わりではない。攻撃者が何を狙い、どの脆弱性を突こうとしているのか。その「ノイズ」の中からシグナルを抽出し、次世代の防衛層へと昇華させるためのインシデント・インテリジェンス・パイプラインの構築について深掘りする。

—

1. 報告エンドポイントの設計：単なるログ収集からの脱却

CSPのレポートを受け取るエンドポイントは、しばしば攻撃者の「セカンダリ・ターゲット」となる。レポートの中身には、ブラウザの実行コンテキストや、場合によっては機微な情報が含まれるからだ。

アーキテクチャの鉄則

隔離されたインフラ: レポート収集用エンドポイントは、メインのAPIサーバーと物理的・論理的に分離せよ。
データ構造の正規化: ブラウザごとに微妙に異なるJSON構造を、ElasticsearchやBigQueryへ投入する前に、共通のスキーマへ変換する「パース・レイヤー」を自前で実装する。

実装例：Goによる軽量かつ安全なレシーバーの骨子

// CSPレポートのスキーマ定義
type CSPReport struct {
Report struct {
DocumentURI string json:"document-uri"
BlockedURI string json:"blocked-uri"
ViolatedDirective string json:"violated-directive"
OriginalPolicy string json:"original-policy"
// 攻撃者が挿入を試みた悪意あるスクリプトの断片が含まれる場合がある
ScriptSample string json:"script-sample"
} json:"csp-report"
}

func handleCSPReport(w http.ResponseWriter, r http.Request) {
// 1. 本番APIとは別の分離されたドメインで受け付ける
// 2. Bodyのサイズを厳格に制限（DoS攻撃対策）
r.Body = http.MaxBytesReader(w, r.Body, 4096)

var report CSPReport
if err := json.NewDecoder(r.Body).Decode(&report); err != nil {
// 不正なJSONは静かに破棄。エラーのスタックトレースをログに出すと攻撃者にヒントを与える
return
}

// 3. ログのサニタイズ（重要）
// 攻撃者が意図的に改行コードや制御文字を埋め込んだログが、SIEMの解析エンジンをクラッシュさせるケースがある
sanitized := sanitize(report)

// 4. メッセージキュー（Kafka/PubSub）へ転送
pushToQueue(sanitized)

w.WriteHeader(http.StatusNoContent)
}

—

2. 攻撃の兆候を見抜く「低レイヤ」の観点

CSPレポートを眺めれば、攻撃者の「手口」が手に取るようにわかる。

インラインスクリプトの試行: violated-directive が script-src で blocked-uri が空、あるいは自社ドメインの場合、攻撃者はHTMLインジェクションを試みている。
データ持ち出しの試行: connect-src の違反。攻撃者が fetch や XMLHttpRequest を使って、ブラウザのストレージやCookieを外部ドメイン（attacker.com）へ送信しようとした形跡だ。
難読化されたペイロード: script-sample にBase64や難読化されたJSコードが含まれている場合、それは自動化されたツールによる「スキャン」ではなく、高度な標的型攻撃の可能性が高い。

監査のポイント

ここで重要なのは、「何が成功したか」ではなく「何が拒否されたか」をカウントすることだ。閾値を超えた特定のセッションからの違反報告は、即座にWAFのブロックリストに自動追加するようオーケストレーションを組むべきである。

—

3. 生成AI時代のガードレイルとプロンプトインジェクションへの応用

現在、我々が直面している最大の変化は「自然言語」が実行コードの一部となりつつあることだ。生成AIを組み込んだアプリケーションにおいて、CSPの思想は「プロンプト・ガードレイル」へと拡張できる。

AIが生成したレスポンスが、意図しないJavaScriptを呼び出そうとしたり、外部ドメインへのリダイレクトを試みた場合、CSPレポートはその最初の防衛線となる。AIの推論結果がDOMを汚染する前に、CSPで「外部スクリプトの実行を禁止」しておくことは、LLMの出力が意図せずコードとして解釈されるリスクに対する最後の砦となる。

—

4. 最後に：現場のエンジニアへ

セキュリティとは、完璧なコードを書くことではない。「システムが侵害されていることをいかに早く、正確に検知するか」という、泥臭い情報の非対称性をコントロールする戦いである。

CSPのレポートエンドポイントを構築することは、言わば「暗闇の中にセンサーを置く」作業だ。最初は膨大なノイズ（主に古いブラウザや拡張機能による誤検知）に悩まされるだろう。だが、そこから「攻撃者の足音」を識別できるようになれば、あなたはただのエンジニアから、侵入を許さない「アーキテクト」へと脱皮できるはずだ。

明日から、君のアプリケーションが発する「警告」に耳を澄ませてほしい。そこに、次のCVEを防ぐ鍵が落ちている。