【テクニカル・上級編】CSPのconnect-srcによるデータ流出防止とAPI通信の制限 – アプリケーションセキュリティ & 安全な開発防御ガイド

境界防衛の最終防壁：CSP connect-src が握るデータ流出阻止の要諦

インジェクション攻撃の歴史は、そのまま「いかにして正規の通信経路を乗っ取るか」という歴史だ。SQLインジェクションでDBを叩き、OSコマンドインジェクションでシェルの制御を奪う。だが、現代の攻撃者が最終的に狙うのは、奪取したトークンや機密データを、いかにして彼らのC2（Command & Control）サーバーへ「持ち出すか」という一点に集約される。

多くのアーキテクトがWAFや入力バリデーションに注力する中、私は常に「もし防御層が突破されたら？」という最悪のケースを想定する。その時、最後に頼りになるのがブラウザのセキュリティポリシー、すなわち Content Security Policy (CSP) の connect-src ディレクティブだ。

1. なぜ connect-src なのか：プロトコルスタックの盲点を突く

攻撃者がXHRやFetch APIを悪用する際、彼らはアプリケーションのフロントエンドが持つコンテキストをそのまま利用する。つまり、セッションクッキーや認証済み状態がそのまま引き継がれる。これを防ぐには、ブラウザの実行エンジンレベルで通信先をホワイトリスト化するしかない。

connect-src は、fetch(), XMLHttpRequest, WebSocket, EventSource, navigator.sendBeacon といった、データ送信の要となるすべてのAPIを制御する。ここを適切に設定していないアプリケーションは、実質的に「攻撃者が自由に外部へデータを送信できるパイプライン」を放置しているに等しい。

2. 実践的アーキテクチャ：厳格なポリシーの構築

ただ適当なドメインを並べるだけでは不十分だ。以下に、本番環境で推奨される堅牢なCSP設定例を示す。

CSPヘッダーの構成例
Content-Security-Policy: default-src ‘self’;
# API通信を自社ドメインと特定の信頼済みエンドポイントのみに制限
connect-src ‘self’ https://api.trusted-partner.com https://analytics.internal.svc;
# インラインスクリプトを排除し、nonceベースでの信頼を強制
script-src ‘self’ ‘nonce-EDNnf03nceIOfn39fn3e9h3’;
# 違反レポートを収集するエンドポイントを明示
report-uri /api/csp-violation-report;

設定の勘所

'self'の重要性: 自社サーバー以外の通信をデフォルトで遮断する。
サブドメインの分離: 可能であれば、API用のサブドメインを専用化し、CDN等とは物理的に分離することで、攻撃者がCDNのキャッシュ汚染等を通じて通信先を偽装するリスクを減らす。
レポート機能の活用: report-to や report-uri は単なるデバッグ用ではない。これは、未知のインジェクション攻撃を検知するための「センサー」だ。突如として未知のドメインへの通信試行がログに現れたら、それは攻撃者がコードを注入し、何らかのデータを外部へ送ろうとした証拠である。

3. 次世代の脅威：AIプロンプトインジェクションとCSPの接点

今、我々が直面している新たな脅威は、生成AIに対するプロンプトインジェクションだ。攻撃者がLLM経由で悪意あるJSONを生成させ、それをフロントエンドのFetch API経由で外部へ送出させるシナリオは、もはや絵空事ではない。

この場合、connect-src は「ガードレイル」として機能する。たとえLLMが騙されて悪意ある外部サーバーへのリクエストを発行しようとしても、ブラウザがポリシーに基づきその通信を遮断する。これは、バックエンドの論理的な防御と、フロントエンドの物理的な防御を組み合わせた「多層防御（Defense in Depth）」の極致と言える。

4. 監査の観点：設定の腐敗を防ぐために

セキュリティのアーキテクチャは、コード同様に「腐敗」する。以下の観点で定期的な監査を行うことを強く推奨する。

1. ワイルドカードの排除: connect-src https://.example.com のような設定は、サブドメインの乗っ取り一つで無効化される。可能な限りFQDNで指定せよ。
2. WebSocketの監視: WebSocketはコネクションが常時接続されるため、CSPの制限をバイパスしやすい。connect-src で wss:// プロトコルを厳格に制限しているか確認が必要だ。
3. 耐量子暗号（PQC）への備え: 将来的な通信の盗聴を考慮すれば、TLS 1.3の強制は必須だが、CSPで通信先を限定しておくことは、将来的に量子計算機によって暗号が解読された際、少なくとも「情報の宛先」を限定し、追跡可能性を確保する防波堤となる。

結論：プロトコルとブラウザを味方につけよ

セキュリティとは、境界線を引く作業だ。connect-src は、その中でも最もシンプルかつ強力な境界線である。多くの開発者は、機能実装の利便性を優先してこの設定を疎かにするが、真にプロフェッショナルなエンジニアは、攻撃者が「出口」を失った時にどれほど無力になるかを理解している。

コードを書くとき、APIエンドポイントを一つ追加するたびに、その通信が本当に必要か、そしてそれをCSPでどう制御すべきかを自問してほしい。その積み重ねこそが、あなたのシステムを堅牢な要塞へと変える唯一の近道である。