CSP（コンテンツセキュリティポリシー）の基礎と考え方

CSPとは何か

CSP（Content Security Policy、コンテンツセキュリティポリシー）は、「このページではどこからのスクリプトや画像、スタイルを読み込んでよいか」をブラウザに伝える仕組みです。ポリシーに反する読み込みや実行はブラウザ側でブロックされます。

万一XSSの隙ができても、外部の不審なスクリプトの読み込みやinline実行を止められれば被害を抑えられます。CSPは脆弱性そのものを直すものではなく、被害を小さくする多層防御の一枚として位置づけられます。

基本のディレクティブ

CSPは「ディレクティブ（指示）」の組み合わせで表現します。代表的なものを押さえると、ポリシーの意図が読み取りやすくなります。

最初から細かく書こうとすると挫折しがちです。まずは既定の許可元を絞るdefault-srcを置き、必要なものだけを足していく引き算の発想が現実的です。

• default-src：他で指定がない場合の既定の許可元をまとめて決める
• script-src：スクリプトの読み込み元を限定する（XSS対策の要）
• style-src：スタイルシートの読み込み元を限定する
• img-src：画像の読み込み元を限定する
• frame-ancestors：このページを他サイトのiframeに埋め込めるかを制御する

よくあるNG例と安全な直し方

CSP（コンテンツセキュリティポリシー）の基礎と考え方では、「検索に出さない」と「見られないようにする」を混同しないことが重要です。noindexやrobots.txtは検索エンジンへの指示であり、アクセス制限そのものではありません。

安全に共有するには、誰に見られると困るかを先に決め、URL共有だけで足りるのか、認証や期限が必要なのかを選びます。共有相手と機密度が決まったら、URLのみ・パスワード・メール認証・会社ドメイン認証のどれで渡すかを選びます。

• NG: 機密情報入りHTMLを認証なしURLで共有し、noindexだけで安心する
• OK: パスワード・メール認証・会社ドメイン認証で閲覧者を絞る
• NG: テスト用APIキーや社内URLをHTML内に残したまま渡す
• OK: 公開前に外部送信先、秘密情報、フォーム送信先を確認する

inlineスクリプトとunsafe-inline

CSPの肝は、HTMLに直書きされたinlineスクリプトを既定で実行させない点にあります。これにより、注入されたスクリプトの実行を防ぎやすくなります。

ただし既存ページはinlineに依存していることが多く、そのままだと動かなくなります。安易にunsafe-inlineで全許可するとXSS対策の効果が薄れます。本来はnonceやhashで「許可するinlineだけ」を指定するのが望ましい方向です。

段階的に導入する手順

CSPはいきなり厳格にするより、観測してから絞るのが安全です。次の流れで進めると、表示崩れや機能停止を避けやすくなります。

1. まず現状ページが何をどこから読み込んでいるかを洗い出す
2. Content-Security-Policy-Report-Onlyで違反を記録だけする（ブロックしない）
3. 報告された違反を見て、正当な読み込み元を許可リストに加える
4. 問題がなくなったらReport-Onlyを外して実際に適用する
5. ページ変更のたびにポリシーを見直し、不要な許可を削る

共有HTMLとCSPの現実的な距離感

自分で運用する本番サイトなら、CSPはサーバのレスポンスヘッダで細かく制御できます。一方、レビューや確認のために他者から受け取ったHTMLを「とりあえず見せる」段階では、そこまで作り込む余裕がないことも多いはずです。

そうした場面では、コードの読み込み元を目視で点検しつつ、見せる相手と期間を絞る運用面の対策が現実的です。ギガサイト便はHTMLをドロップして即共有でき、URLのみ・パスワード・メール認証・会社ドメイン認証から閲覧範囲を選べます。CSPで守りきれない確認段階こそ、認証と公開期限で「誰にいつまで見せるか」を管理する価値があります。