ApacheでCSPヘッダーを設定しXSSを防止する方法を徹底解説

Apacheサーバーで運用されるWebサイトは、多くのユーザーに利用される一方で、攻撃の対象にもなりやすいです。特にXSS（クロスサイトスクリプティング）攻撃は、サイトに悪意のあるスクリプトを埋め込むことで、ユーザーの情報を盗み出したり、不正な操作を実行させたりします。
このような攻撃を防ぐために有効な手段の一つがContent-Security-Policy（CSP）ヘッダーの設定です。CSPは、ブラウザに対してスクリプトの実行元やリソースの読み込み元を制限することで、不正なスクリプトが実行されるのを防ぎます。

本記事では、ApacheサーバーでCSPを設定する方法について、初心者でも理解しやすいように詳しく解説します。基本的なCSPの概念から、Apacheでの設定方法、運用時のテスト、よくあるミスの回避方法まで幅広く紹介します。これを参考にして、Webサイトのセキュリティを強化しましょう。

XSS攻撃とは何か

XSS（クロスサイトスクリプティング）とは、Webサイトの脆弱性を利用して、悪意のあるスクリプトをユーザーのブラウザ上で実行させる攻撃手法です。攻撃者はこれを用いて、ユーザーの個人情報を盗んだり、フィッシング詐欺を行ったり、サイトの改ざんを試みます。

XSSの仕組み

XSS攻撃は、サイトにユーザーが入力できるフォームやコメント欄などを利用して行われます。攻撃者は、以下のように悪意のあるJavaScriptコードを埋め込みます。

<input type="text" name="name" value="<script>alert('XSS');</script>">

これが処理されると、ユーザーのブラウザでスクリプトが実行されてしまいます。

XSSの主な種類

XSS攻撃には主に以下の3種類があります。

1. 反射型XSS（Reflected XSS）

攻撃者が作成したリンクをクリックした際に、不正なスクリプトがブラウザで即座に実行されます。

2. 永続型XSS（Stored XSS）

悪意のあるスクリプトがサーバーに保存され、サイトの利用者全員が攻撃の対象になります。掲示板やコメント欄などが狙われやすいです。

3. DOMベースXSS

クライアントサイドのスクリプトを直接操作して、不正な動作を引き起こします。ページのDOMを操作するJavaScriptが攻撃対象です。

XSSの影響

XSS攻撃が成功すると、以下のような被害が発生します。

• ユーザーのセッションハイジャック
• 個人情報の漏洩
• サイトの見た目や内容の改ざん
• フィッシング詐欺の実行

XSS攻撃は非常に広範囲に影響を与えるため、サイトのセキュリティ対策として早急な対応が求められます。CSPを導入することで、これらの攻撃を未然に防ぐことが可能になります。

Content-Security-Policy（CSP）の概要

Content-Security-Policy（CSP）は、Webアプリケーションのセキュリティを向上させるためのHTTPヘッダーです。ブラウザに対して、許可されたリソースの読み込み元やスクリプトの実行元を指定することで、XSS（クロスサイトスクリプティング）やデータインジェクション攻撃を防ぎます。

CSPの仕組み

CSPは「ポリシー」と呼ばれるルールをブラウザに送信し、リソースのロードやスクリプトの実行を制限します。ブラウザは、指定されたポリシーに違反するリソースをブロックし、不正なスクリプトの実行を防ぎます。
例えば、外部サイトからのスクリプト読み込みを防ぐポリシーを適用することで、不正なスクリプトのインジェクションを阻止します。

CSPの主な効果

• XSS攻撃の防止：外部スクリプトやインラインスクリプトの実行を制限し、不正なコードの挿入を防ぎます。
• データインジェクション防止：画像、スタイルシート、メディアファイルなどの外部リソースが制限されます。
• セキュリティ向上：外部CDNや第三者ライブラリの使用を必要最小限にすることで、攻撃対象領域を縮小します。

CSPの基本的な仕組み

CSPポリシーは、HTTPレスポンスヘッダーとして送信されます。以下は基本的なCSPヘッダーの例です。

Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.example.com

このポリシーは、次のことを意味します。

• default-src 'self'：すべてのリソース（スクリプト、画像、スタイルなど）は同一オリジン（’self’）からのみ読み込まれます。
• script-src 'self' https://trustedscripts.example.com：スクリプトは同一オリジンまたはtrustedscripts.example.comからのみ読み込み可能です。

主なディレクティブ

• default-src：すべてのリソースに対するデフォルトの読み込み元を指定。
• script-src：JavaScriptの読み込み元を制限。
• style-src：CSSの読み込み元を指定。
• img-src：画像の読み込み元を制限。
• connect-src：AjaxやWebSocketなど、ネットワーク接続の許可元を指定。

CSPは非常に柔軟で強力なセキュリティ対策であり、正しく設定することで、Webサイトの安全性を大幅に向上させることができます。

ApacheでCSPを設定する方法

ApacheでContent-Security-Policy（CSP）を設定するには、HTTPレスポンスヘッダーを追加する必要があります。これにより、ブラウザがリソースの読み込みやスクリプトの実行を制御し、不正なコードの実行を防ぎます。

1. Apacheの設定ファイルを編集する

CSPヘッダーを設定するためには、Apacheの設定ファイル（httpd.confや各サイトの仮想ホスト設定ファイル）を編集します。

対象ファイル例

• 全体の設定：/etc/httpd/conf/httpd.conf
• サイトごとの設定：/etc/httpd/conf.d/example.com.conf
• .htaccessで個別ページごとに設定

2. CSPヘッダーを追加する

以下のようにHeaderディレクティブを使用して、CSPポリシーを追加します。

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://trustedscripts.example.com"
</IfModule>

• mod_headersが有効であることを確認してください。
• ポリシーの内容はサイトの要件に応じて調整します。

3. `.htaccess`ファイルで設定する方法

特定のディレクトリやページのみにCSPを適用する場合は、.htaccessファイルに記述します。

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; img-src 'self' data:; script-src 'self' https://apis.example.com"
</IfModule>

この方法は、Apache全体に影響を与えず、必要な部分だけにCSPを適用できます。

4. 設定の反映と確認

Apacheの設定を反映させるために、サーバーを再起動します。

sudo systemctl restart httpd

設定が反映されているかどうかを確認するには、ブラウザの開発者ツールでレスポンスヘッダーを確認します。

curl -I https://example.com

このコマンドでContent-Security-Policyヘッダーが表示されていれば、正しく設定されています。

5. 設定後の注意点

• 不適切なCSP設定は、正規のリソースまでブロックする可能性があります。
• 段階的に設定し、問題が発生しないかテストを行いながら調整してください。
• レポートモードでテストを行い、問題が発生したリソースを確認してからポリシーを本番適用することを推奨します。

ApacheでのCSP設定は、XSS攻撃防止に非常に効果的です。適切なポリシーを策定し、安全なWebサイト運営を心がけましょう。

CSPヘッダーの具体例とディレクティブ解説

Content-Security-Policy（CSP）ヘッダーの効果を最大限に引き出すには、ディレクティブを適切に設定する必要があります。CSPは柔軟性が高く、さまざまなシナリオに対応可能です。ここでは具体例を挙げながら、主要なディレクティブの役割と使い方を解説します。

1. 基本的なCSPの例

Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.example.com; object-src 'none'

解説：

• default-src 'self'：すべてのリソースは同一オリジン（’self’）からのみ読み込み可能です。
• script-src 'self' https://trustedscripts.example.com：スクリプトの読み込みは同一オリジンまたはtrustedscripts.example.comのみ許可されます。
• object-src 'none'：<object>, <embed>, <applet>タグの使用を禁止します。

2. 画像やフォントの読み込みを制限する例

Content-Security-Policy: img-src 'self' https://images.example.com; font-src 'self' data:

解説：

• img-src 'self' https://images.example.com：画像の読み込みは同一オリジンとimages.example.comからのみ許可されます。
• font-src 'self' data:：フォントの読み込みは同一オリジンまたはdata:スキームでベース64エンコードされたフォントのみ許可されます。

3. 外部スタイルシートの利用を許可する例

Content-Security-Policy: style-src 'self' 'unsafe-inline' https://cdn.example.com

解説：

• style-src 'self' 'unsafe-inline' https://cdn.example.com：スタイルシートは同一オリジン、インラインスタイル（'unsafe-inline'）、およびcdn.example.comから読み込み可能です。
• 'unsafe-inline'はXSSのリスクがあるため、必要がない場合は省略します。

4. フレームやiframeの制御

Content-Security-Policy: frame-ancestors 'self' https://trustedpartners.com

解説：

• frame-ancestors 'self' https://trustedpartners.com：iframeでの埋め込みは同一オリジンおよびtrustedpartners.comからのみ許可されます。

5. 動的データの送信やWebSocketの制御

Content-Security-Policy: connect-src 'self' wss://api.example.com

解説：

• connect-src 'self' wss://api.example.com：AjaxリクエストやWebSocket接続は同一オリジンおよびapi.example.com経由のみ許可されます。

主なディレクティブ一覧

• default-src：すべてのリソースのデフォルト読み込み元を指定。
• script-src：JavaScriptの読み込み元を制限。
• style-src：スタイルシートの読み込み元を指定。
• img-src：画像の読み込み元を指定。
• connect-src：AjaxやWebSocketなどの接続先を制限。
• font-src：フォントの読み込み元を制限。
• object-src：<object>や<embed>の使用を制限。
• media-src：音声や動画の読み込み元を指定。
• frame-ancestors：<iframe>の埋め込み元を制御。

注意点

• unsafe-inlineやunsafe-evalの使用はXSSのリスクを高めるため、必要最低限に留めましょう。
• すべてのリソースを制限する際は、default-src 'none'を設定した上で、個別に許可するディレクティブを記述します。
• ポリシーを厳密にしすぎるとサイトが正常に動作しない場合があるため、テストを重ねながら調整します。

CSPは非常に強力ですが、柔軟に運用することでサイトのセキュリティを大幅に向上させることができます。

レポートモードでCSPをテストする方法

Content-Security-Policy（CSP）を本番環境で適用する前に、レポートモードを使って動作確認を行うことで、サイトの機能を損なわずに問題点を特定できます。レポートモードでは、CSPポリシー違反があった場合にブラウザがログを記録するだけで、リソースのブロックは行いません。これにより、問題のあるスクリプトやリソースを把握し、安全にポリシーを改善できます。

1. レポートモード用CSPの記述方法

通常のCSPポリシーと同様にHTTPヘッダーで指定しますが、レポートモードではContent-Security-Policy-Report-Onlyヘッダーを使用します。

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trustedscripts.example.com; report-uri /csp-violation-report

解説：

• Content-Security-Policy-Report-Only：ポリシー違反時にリソースをブロックせず、ログだけを記録します。
• report-uri：違反があった際にレポートを送信するエンドポイントを指定します。

2. Apacheでレポートモードを設定する

Apacheの設定ファイルや.htaccessにレポートモードのCSPヘッダーを追加します。

<IfModule mod_headers.c>
    Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://trusted.example.com; report-uri /csp-report-endpoint"
</IfModule>

この設定を行った後、Apacheを再起動して設定を反映させます。

sudo systemctl restart httpd

3. レポートの受け取り方法

report-uriで指定したエンドポイントに対して、CSP違反が発生すると以下のようなJSON形式でレポートが送信されます。

{
  "csp-report": {
    "document-uri": "https://example.com/index.html",
    "referrer": "",
    "blocked-uri": "https://malicious.example.com/script.js",
    "violated-directive": "script-src-elem",
    "original-policy": "default-src 'self'; script-src 'self' https://trusted.example.com; report-uri /csp-report-endpoint"
  }
}

主なフィールド解説：

• document-uri：CSP違反が発生したページのURL
• blocked-uri：ブロックされたリソースのURL
• violated-directive：違反したディレクティブ
• original-policy：適用されていたCSPポリシー

4. 簡易レポート受け取り用スクリプト

違反レポートを受け取るための簡単なスクリプトをサーバーに設置します。

<?php
  $data = file_get_contents("php://input");
  file_put_contents("csp_reports.log", $data . PHP_EOL, FILE_APPEND);
?>

このスクリプトを/var/www/html/csp-report-endpointに設置することで、CSP違反レポートをログファイルに記録できます。

5. レポート内容の確認と改善

記録されたレポートを元に、ポリシーの調整を行います。

• 不要なスクリプトや外部リソースの排除
• 許可が必要なリソースの特定とポリシーの更新

6. 本番環境への適用

レポートモードで問題がないことを確認したら、Content-Security-Policy-Report-OnlyをContent-Security-Policyに変更してポリシーを適用します。

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.example.com"
</IfModule>

7. テスト後の確認

適用後は、ブラウザの開発者ツールでCSPが正常に動作しているかを確認し、意図しないリソースがブロックされていないか確認します。

CSPのレポートモードを活用することで、リスクを最小限に抑えつつ、セキュリティポリシーを適切に導入することが可能です。

実際にCSP違反が発生した際のログ確認方法

Content-Security-Policy（CSP）を導入すると、ポリシー違反が発生した場合にリソースがブロックされます。CSP違反が発生した際には、ブラウザが詳細なエラーをログに記録するため、問題の特定や修正が容易になります。ここでは、CSP違反のログを確認する具体的な方法を解説します。

1. ブラウザの開発者ツールで確認する

最も簡単にCSP違反を確認できるのは、ブラウザの開発者ツールを利用する方法です。

確認手順

1. Webサイトを開いた状態で、ブラウザの「開発者ツール」を起動します。

• Chrome：F12 または Ctrl + Shift + I
• Firefox：F12 または Ctrl + Shift + I
• Edge：F12 または Ctrl + Shift + I

1. 「コンソール」タブを開きます。
2. CSP違反が発生した場合、以下のようなエラーが表示されます。

Refused to load the script 'https://untrusted.example.com/malicious.js' because it violates the following Content Security Policy directive: "script-src 'self'".

解説：

• Refused to load the script：スクリプトの読み込みが拒否されたことを示します。
• https://untrusted.example.com/malicious.js：ブロックされたリソースのURLです。
• script-src 'self'：適用されているポリシーの内容です。

2. HTTPレスポンスヘッダーでCSPレポートを確認する

CSP違反が発生した場合、違反の詳細がContent-Security-Policy-Report-Onlyヘッダーを通じて記録されます。curlコマンドを使用して、ヘッダーの内容を確認できます。

curl -I https://example.com

レスポンス内にContent-Security-PolicyやContent-Security-Policy-Report-Onlyが含まれているかを確認します。

3. サーバーログで確認する

report-uriディレクティブを使用して、違反が発生した場合にサーバーへレポートを送信する設定ができます。

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trusted.example.com; report-uri /csp-violation-log

違反が発生した場合、以下のようなJSON形式のログが送信されます。

{
  "csp-report": {
    "document-uri": "https://example.com",
    "referrer": "https://referrer.example.com",
    "blocked-uri": "https://untrusted.example.com",
    "violated-directive": "script-src-elem",
    "original-policy": "default-src 'self'; script-src 'self'"
  }
}

レポートログの保存例

サーバー側でログを受け取るPHPスクリプトを以下のように設置します。

<?php
  $data = file_get_contents("php://input");
  file_put_contents("/var/log/csp_violations.log", $data . PHP_EOL, FILE_APPEND);
?>

このスクリプトを/var/www/html/csp-violation-logに設置すれば、違反が記録されます。

4. 実際のログ例

以下はCSP違反のログ例です。

{
  "csp-report": {
    "document-uri": "https://example.com/dashboard",
    "referrer": "https://example.com/home",
    "blocked-uri": "https://cdn.malicious.com/hack.js",
    "violated-directive": "script-src-elem",
    "original-policy": "default-src 'self'; script-src 'self'"
  }
}

ポイント：

• blocked-uriはブロックされたリソースです。
• violated-directiveは違反したCSPポリシーを示します。

5. 問題が発生した場合の対応方法

1. blocked-uriを確認し、そのリソースが必要な場合はCSPポリシーに追加します。
2. 必要ない場合は、該当のスクリプトやリソースを削除します。
3. テスト環境でレポートモードを使い、再度問題がないか確認します。

6. 注意点

• レポートURIは慎重に設計する必要があります。攻撃者がレポートエンドポイントを悪用する可能性があるためです。
• JSONログを分析し、不要な外部リソースがブロックされていないか慎重に確認しましょう。

CSP違反のログ確認を徹底することで、潜在的なセキュリティリスクを迅速に検出し、安全なサイト運用が可能になります。

よくあるCSP設定ミスとその対処法

Content-Security-Policy（CSP）の設定は強力なセキュリティ対策ですが、間違った設定を行うとサイトの正常な動作を妨げたり、セキュリティが十分に機能しなくなる可能性があります。ここでは、CSP設定でよく見られるミスとその対処法について解説します。

1. インラインスクリプトやスタイルを許可してしまう

ミスの例：

Content-Security-Policy: script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'

問題点：

• unsafe-inlineを使用すると、インラインスクリプトやスタイルが許可され、XSS攻撃のリスクが高まります。
• 攻撃者がインラインで悪意のあるJavaScriptを埋め込む可能性があります。

対処法：

• インラインスクリプトの代わりに外部ファイルを使用するか、nonceやhashを使用して特定のスクリプトだけを許可します。

修正例：

Content-Security-Policy: script-src 'self' 'nonce-abc123'; style-src 'self'

• nonce-abc123は安全なスクリプトにのみ付与され、他のインラインスクリプトはブロックされます。

2. 外部リソースの許可範囲が広すぎる

ミスの例：

Content-Security-Policy: script-src *; img-src *; connect-src *

問題点：

• すべての外部リソースを許可してしまうため、信頼できないサーバーからのリソースが実行される可能性があります。

対処法：

• 信頼できるドメインのみを許可するようにポリシーを限定します。
• 必要最低限のリソースに絞り込みましょう。

修正例：

Content-Security-Policy: script-src 'self' https://apis.trusted.com; img-src 'self' https://cdn.trusted.com

3. report-uriが設定されていない

ミスの例：

Content-Security-Policy: default-src 'self'

問題点：

• 違反が発生しても検知ができないため、どのリソースが問題を引き起こしているか把握できません。

対処法：

• report-uriを設定し、違反があればレポートを受け取れるようにします。

修正例：

Content-Security-Policy: default-src 'self'; report-uri /csp-report

• report-uriで指定したエンドポイントでCSP違反のログを確認できます。

4. 必要なリソースがブロックされる

ミスの例：

Content-Security-Policy: default-src 'self'

問題点：

• 外部の必要なAPIやCDNからのリソースが読み込まれず、機能が正常に動作しなくなる場合があります。

対処法：

• 必要な外部リソースを明示的に許可します。
• 設定を段階的に適用し、レポートモードでテストを行います。

修正例：

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com

5. フレーム埋め込みが不要に許可されている

ミスの例：

Content-Security-Policy: frame-src *

問題点：

• 任意のサイトからiframeでコンテンツが埋め込まれる可能性があり、クリックジャッキング攻撃に繋がります。

対処法：

• frame-ancestorsディレクティブを使用し、埋め込みを特定のドメインに限定します。

修正例：

Content-Security-Policy: frame-ancestors 'self' https://trustedpartner.com

6. すべてを禁止してしまう設定

ミスの例：

Content-Security-Policy: default-src 'none'

問題点：

• すべてのリソースがブロックされ、ページが正しく表示されなくなる可能性があります。

対処法：

• default-src 'none'の設定を基に、必要なリソースを個別に許可します。

修正例：

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

まとめ

CSPは強力なセキュリティ対策ですが、設定を誤るとWebサイトの動作に支障をきたすことがあります。レポートモードを活用して、CSPポリシーを段階的に導入し、問題が発生した場合にはログを確認して修正することが重要です。適切に設定されたCSPは、XSS攻撃などのセキュリティリスクを大幅に軽減します。

応用：特定ページごとのCSP設定方法

Webサイト全体にContent-Security-Policy（CSP）を適用するだけでなく、ページごとに異なるポリシーを設定することで、セキュリティと利便性のバランスを取ることができます。特定のページで外部リソースを利用する場合や、管理画面のみより厳格なポリシーを適用したい場合などに有効です。ここでは、ページやディレクトリ単位でCSPを設定する方法を解説します。

1. `.htaccess`で特定のディレクトリにCSPを設定する

Apacheでは、.htaccessファイルを使用して特定のディレクトリやページに異なるCSPポリシーを適用できます。

例：管理画面/adminにはより厳格なCSPを適用する場合

<IfModule mod_headers.c>
    <Directory "/var/www/html/admin">
        Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'none'"
    </Directory>
</IfModule>

解説：

• /adminディレクトリ内では、外部リソースやiframeの埋め込みを禁止するポリシーが適用されます。
• これにより、管理画面への不正なスクリプトやiframeの攻撃を防止できます。

2. 特定のページにCSPを設定する

個別のページにCSPを適用するには、.htaccessでFilesディレクティブを使用します。

例：ログインページlogin.htmlにのみCSPを設定する場合

<IfModule mod_headers.c>
    <Files "login.html">
        Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.cdn.com"
    </Files>
</IfModule>

解説：

• login.htmlでは信頼された外部CDNからのスクリプトのみ許可されます。
• 他のページには影響を与えずに、必要なページだけCSPを設定できます。

3. 動的にCSPを生成する方法（PHPを利用）

動的なページや条件によってCSPを変更したい場合は、サーバーサイドスクリプト（PHPなど）を活用してレスポンスヘッダーを動的に生成します。

例：ログイン状態やユーザー権限に応じてCSPを切り替える

<?php
    $isAdmin = true; // 管理者かどうかの判定
    if ($isAdmin) {
        header("Content-Security-Policy: default-src 'self'; script-src 'self'; frame-ancestors 'none'");
    } else {
        header("Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com");
    }
?>

解説：

• 管理者ページでは外部スクリプトを禁止し、一般ユーザーには外部CDNを許可するポリシーを適用しています。
• 柔軟にCSPを適用でき、ユーザーの状態に応じたポリシー管理が可能です。

4. 特定のコンテンツタイプにCSPを適用する

MIMEタイプに基づいてCSPを適用することで、特定のコンテンツだけに制限を加えることができます。

例：HTMLコンテンツにのみCSPを適用する

<IfModule mod_headers.c>
    <FilesMatch "\.html$">
        Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.example.com"
    </FilesMatch>
</IfModule>

解説：

• .htmlファイルにのみCSPを適用し、画像やPDFなどの他のファイルには影響を与えません。
• 柔軟な制御が可能になります。

5. 複数のCSPを併用する方法

複数のCSPポリシーを同時に適用することで、細かくセキュリティレベルを設定できます。Content-Security-PolicyとContent-Security-Policy-Report-Onlyを併用することで、ポリシーをテストしながら運用できます。

例：本番用とレポート用のCSPを同時に設定

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.example.com"
    Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'none'; report-uri /csp-violation-log"
</IfModule>

解説：

• Content-Security-Policyは本番で動作し、Content-Security-Policy-Report-Onlyは違反をログに記録するだけのモードになります。
• レポートモードで発生した違反を元に、本番ポリシーを段階的に改善できます。

6. ページごとのCSP設定例

• 管理画面：default-src 'self'; frame-ancestors 'none'; object-src 'none'
• 公開ページ：default-src 'self'; script-src 'self' https://cdn.example.com
• APIエンドポイント：default-src 'none'; connect-src 'self'

まとめ

ページごとにCSPを適用することで、必要なリソースだけを許可し、セキュリティを強化できます。サイト全体で一律のポリシーを適用するのではなく、ページや機能に応じた柔軟なCSP設定を行うことで、利便性を損なわずにセキュリティを向上させましょう。

まとめ

本記事では、ApacheでContent-Security-Policy（CSP）を設定し、XSS攻撃を防止する方法について解説しました。CSPは、Webサイトのセキュリティを大幅に強化する重要な技術であり、適切に設定することで外部からのスクリプト注入やリソースの不正な読み込みを防ぐことができます。

特に、レポートモードを活用してポリシーを段階的に適用し、問題がないか確認しながら運用することが重要です。また、ページごとやディレクトリ単位で柔軟にCSPを設定することで、利便性とセキュリティを両立させることができます。

CSPの導入と継続的な改善により、安全で信頼性の高いWebサイト運営を目指しましょう。