【実務・中級編】CSPのreport-uriおよびreport-toによる違反レポートの収集と監視 – アプリケーションセキュリティ & 安全な開発防御ガイド

CSP違反レポート：攻撃の「予兆」を捉えるための最前線運用術

現場でインシデント対応をしていると痛感するのだが、多くのエンジニアが「CSP（Content Security Policy）は厳しく設定すればするほど画面が壊れる」という恐怖心から、結局 unsafe-inline を許容して骨抜きにしている。

だが、CSPの真の価値は「防御」だけにあるのではない。「違反レポートの監視」こそが、攻撃の初期段階（偵察・プロファイリング）を検知する最強の防波堤になるということを忘れないでほしい。

今日は、ただCSPを導入するだけでなく、report-uri や report-to を活用して、攻撃者の息遣いをログとしてキャプチャする仕組みを構築する話をしよう。

—

なぜ、CSPレポートが「攻撃の予兆」になるのか

攻撃者は、いきなり本丸のSQLインジェクションを仕掛けてくるわけではない。まずはXSSを仕込み、そこからブラウザのCookieを盗み出し、管理者画面への侵入経路を探る。

もし、貴方のサイトで「意図しないドメインへのスクリプト読み込み」や「インラインスクリプトの実行」が発生した際、それがCSPレポートとして飛んできたらどう思う？それは単なる設定ミスかもしれないが、攻撃者が脆弱性をテストしている痕跡である可能性が高い。

この「ノイズ」を放置するのではなく、分析対象としてログ基盤へ流し込むことが、プロの運用だ。

—

1. 実装の基本：レポート送信先の定義（Nginx設定）

まずは、HTTPレスポンスヘッダーでCSPを定義する。現在は report-uri が非推奨となり、次世代の report-to への移行期だが、互換性のために両方記述しておくのが現実的な解だ。

Nginxの設定例：セキュリティヘッダーの定義
add_header Content-Security-Policy “default-src ‘self’; \
script-src ‘self’ https://trusted.cdn.com; \
object-src ‘none’; \
report-uri /csp-violation-report-endpoint; \
report-to csp-group;”;

Report-Toヘッダー（ブラウザへの通知先グループ定義）
add_header Report-To ‘{“group”:”csp-group”,”max_age”:10886400,”endpoints”:[{“url”:”https://logging.your-domain.com/csp-report”}]}’;

—

2. レポート収集エンドポイントの構築（Python/Flask）

受け取ったレポートをそのまま放置しては意味がない。バックエンドで受け取り、構造化ログとして出力するエンドポイントを作る。ここではPythonのFlaskを用いたミニマムな実装例を示す。

from flask import Flask, request, jsonify
import logging

app = Flask(__name__)

ログ設定：SIEM（DatadogやELK）へ流し込みやすいJSON形式にする
logging.basicConfig(level=logging.INFO, format=’%(asctime)s – %(message)s’)
logger = logging.getLogger(“csp_monitor”)

@app.route(‘/csp-violation-report-endpoint’, methods=[‘POST’])
def csp_report():
# ブラウザから送られてくるレポート本体
report = request.get_json(force=True)

# 攻撃検知のポイント:
# blocked-uri や violated-directive を見て異常なドメインが含まれていないか監視する
if report:
logger.warning(f”CSP Violation Detected: {report}”)
# ここでSlack通知やPagerDutyへのトリガーを仕込むのが実務的

return ”, 204 # ブラウザには成功を返す

if __name__ == ‘__main__’:
app.run(port=8080)

—

3. 実務的な運用上の盲点：何を見るべきか？

レポートが集まり始めると、最初はあまりの「ノイズの多さ」に驚くはずだ。ブラウザ拡張機能や、誤検知によるレポートが山のように届くからだ。ここで挫折してはいけない。

監視すべきは以下のパターンだ：

blocked-uri が未知の外部ドメイン: 攻撃者が自前のC2サーバーや悪意あるスクリプトホストへデータを送信しようとしている。
violated-directive が script-src 以外: connect-src や frame-ancestors への違反は、より高度なデータ持ち出しやクリックジャッキングの試行であることが多い。
急激なレポート増加: 特定のIPやユーザーエージェントから集中してレポートが上がる場合、それは間違いなく「攻撃者が脆弱性スキャナを回している」瞬間だ。

—

まとめ：防御から「検知」への意識転換を

CSPの設定を「完璧」にしようとして、開発の足を止めてはいけない。「まずレポート収集を始め、何が起きているか可視化する」ことこそが、開発スピードとセキュリティを両立させる唯一の道だ。

レポートをSIEMに流し込み、ダッシュボードで異常を監視する。もし、見慣れない外部ドメインへの接続試行がレポートされたら、その瞬間に貴方は攻撃の「初動」を掴んだことになる。

セキュリティとは、穴を塞ぐだけの作業ではない。攻撃者の足音を、いち早く聞くための努力そのものなのだ。さあ、今すぐCSPレポートの収集設定をマージしてくれ。それが、貴方のシステムを守る最強の武器になるはずだ。