Webアプリケーションのセキュリティ対策として、入力値の検証や出力時のエスケープはよく知られています。しかし、それだけではすべての攻撃を防げるわけではありません。

そこで重要になるのが Content Security Policy（CSP） です。

CSPはブラウザ側で実行されるセキュリティポリシーであり、不正なスクリプトやリソースの読み込みを制限することで、XSS（Cross-Site Scripting）などのリスクを軽減できます。

CSPとは？

Content Security PolicyはHTTPレスポンスヘッダーとして設定されるセキュリティ機能です。

例えば、以下のようなヘッダーを設定できます。

Content-Security-Policy:
default-src 'self';
script-src 'self';
style-src 'self';
img-src 'self' https:;

この設定では、

というルールになります。

CSPが必要な理由

仮に悪意のあるJavaScriptがページへ挿入された場合でも、CSPによって実行を制限できる可能性があります。

例えば、

<script src="https://example-malicious.com/attack.js"></script>

のような外部スクリプトが挿入されても、許可されていないドメインであればブラウザが読み込みを拒否します。

このように、CSPは「最後の防御線」として機能します。

すべてのリソースの基本ルールを定義します。

default-src 'self';

JavaScriptの読み込み元を制限します。

script-src 'self';

CDNを利用する場合は、必要なドメインのみを追加します。

script-src 'self' https://cdn.example.com;

CSSの取得元を制御します。

style-src 'self';

画像の取得元を指定します。

img-src 'self' https:;

API通信やFetch、WebSocketなどの接続先を制御します。

connect-src 'self' https://api.example.com;

SPAやフロントエンドアプリケーションでは特に重要な設定です。

インラインスクリプトを安全に利用したい場合は、nonceを利用できます。

Content-Security-Policy:
script-src 'self' 'nonce-random123';

HTML側では同じ値を指定します。

<script nonce="random123">
console.log("Hello");
</script>

これにより、許可されたスクリプトだけが実行されます。

本番環境へ導入する前に、

Content-Security-Policy-Report-Only

を利用すると、安全に影響範囲を確認できます。

ポリシー違反があっても処理はブロックされず、レポートだけを収集できます。

運用開始前の検証には非常に便利です。

CSPを厳しく設定しすぎると、正規のJavaScriptやCSSまで読み込めなくなることがあります。

そのため、

といった進め方がおすすめです。

近年のデジタルサービスでは、パフォーマンスだけでなくセキュリティもユーザー体験の重要な要素になっています。

例えば、JLPH のようなオンラインデジタルプラットフォームを参考に考えると、ログイン画面やアカウント管理機能などでは、安全なスクリプト実行環境を維持することが求められます。CSPをはじめとするブラウザセキュリティ機能を適切に構成することで、より堅牢なWebアプリケーション設計につながります。

Content Security Policyは、XSS対策を強化するための重要なセキュリティ機能です。

入力値の検証やエスケープと組み合わせることで、多層的な防御を実現できます。

まずは Report-Onlyモード を利用して既存サイトへの影響を確認し、その後に段階的な導入を進めることで、安全性と互換性のバランスを取りながら運用できるでしょう。Webアプリケーションを開発する際には、CSPを基本的なセキュリティ対策の一つとして取り入れることをおすすめします。