エンジニアの皆さん、こんにちは。ネットワークの深淵を愛するインフラアーキテクトです。
API開発というと、つい「どんなデータを返すか（JSONの構造）」にばかり目が行きがちですよね。しかし、実はそのデータを「どうやって安全にブラウザという大海原へ届けるか」という配送のルール（HTTPヘッダー）こそが、プロの腕の見せ所です。
今回は、APIのセキュリティの守護神、Content-Security-Policy（CSP）について、郵便の仕組みになぞらえて紐解いていきましょう。
—
郵便物に「送り先制限」をかける理由
想像してみてください。あなたは大切な手紙（APIレスポンス）を送る際、差出人や内容を偽装して悪さをする「なりすまし」が心配でたまりません。
ブラウザという場所は、実は非常に「お人好し」です。サーバーから届いた手紙に「このスクリプトを実行して！」と書いてあれば、たとえそれが悪意のある第三者が送りつけた偽の手紙であっても、律儀に実行してしまいます。これが世に言う「クロスサイトスクリプティング（XSS）」の恐怖です。
そこで登場するのが Content-Security-Policy です。これは、「この手紙の中に書いてある命令は、信頼できる差出人からのものだけを実行しなさい」と、宛先に送る「受取許可証」のようなものなのです。
—
CSPの基本的な考え方：信頼できる「配送センター」を指定する
CSPを設定する際、私たちはブラウザに対して「ここからの情報なら信じていいよ」というホワイトリストを渡します。
例えば、「自分のサイトのスクリプトはOKだけど、怪しい外部サイトからのスクリプトは絶対に実行しちゃダメ！」と指示を出すわけです。
実際にヘッダーを書いてみよう
APIのレスポンスヘッダーに、以下のような設定を追加します。
# ブラウザに送るセキュリティ設定の例
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com;それぞれの意味を噛み砕いてみますね。
default-src 'self'：基本的には「自分のサーバー（自ドメイン）」から読み込んだものだけを許可します。script-src 'self' https://trusted.cdn.com：スクリプトに関しては、「自分」と「許可したCDN（https://trusted.cdn.com）」だけを信頼します。
これだけで、ブラウザは「おっ、これ以外の場所からのスクリプトは実行しなくていいんだな」と理解し、悪意のあるインジェクション攻撃を未然に防いでくれるようになります。
—
インフラ構築の現場で意識する「泥臭い」ポイント
現場でCSPを導入しようとすると、必ずぶつかる壁があります。「厳しく設定しすぎて、本当に必要なスクリプトまで動かなくなってしまった！」というケースです。
これを回避するために、最初は「報告モード」で運用するのがプロの鉄則です。
違反を通知してもらう設定
Content-Security-Policy-Report-Only というヘッダーを使うと、ブラウザは「もしこのルールが適用されていたらブロックしていたはずの通信」を、開発者にこっそり教えてくれます。
# まずはブロックせずに、違反レポートだけ飛ばしてもらう設定
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /api/csp-violation-report;/api/csp-violation-report というエンドポイントを自分で用意しておけば、どのページでどのようなスクリプトが引っかかっているのか、ログとして蓄積できます。これを分析して、少しずつホワイトリストを拡充していく……この「安全を確認しながら網を狭めていく」プロセスこそが、インフラ構築の醍醐味です。
—
まとめ：APIは「届け方」までが設計です
APIのエンドポイントURLを美しく設計することも大切ですが、そこに流れるデータがブラウザという環境でどう扱われるかまで配慮してこそ、真の意味での「堅牢なアーキテクチャ」と言えます。
1. ブラウザを信じすぎない：CSPはブラウザという受取人への「最強の注意書き」です。
2. まずはReport-Onlyから：いきなり厳格にすると現場が混乱します。まずは状況を把握しましょう。
3. 最小権限の原則：必要最小限のドメインだけを許可するよう、日々メンテナンスを心がけてください。
ネットワークの世界は奥が深く、そして非常に論理的です。最初は難しく感じるかもしれませんが、こうして「郵便配達」や「許可証」に例えると、パケットがどんな意図で流れているのかが見えてくるはずです。
皆さんのAPIが、今日も安全に、そして美しくブラウザへ届くことを願っています。それでは、また次回の深淵でお会いしましょう！
コメント