Posted inSecurity

Nginx & ApacheのCSP設定：Webサイトを守る強力なXSS対策「盾」

Security tutorial - IT technology blog
Security tutorial - IT technology blog

なぜセキュリティ対策にやりすぎはないのか？

ぶっちゃけた話、私のセキュリティに対する慎重さは、過去の「苦い経験」から来ています。駆け出しの頃、サーバーが1時間あたり1万リクエスト以上のブルートフォース攻撃を受け、夜中の3時まで対応に追われたことがあります。あの時は本当に生きた心地がしませんでした。顧客データが流出するのではないかと、心臓がバクバクして足が震えました。その手痛い教訓から学んだのは、セキュリティは最初から万全にしておくべきだということです。そして、最強の「武器」の一つが、Content Security Policy (CSP) です。

Webサイトを家に例えてみましょう。SSL/HTTPSはしっかりした玄関の鍵です。しかし、XSSの脆弱性が残っているなら、窓が全開になっているのと同じです。泥棒はいつでも「毒」（悪意のあるスクリプト）を投げ込むことができます。CSPは、その窓に取り付ける防護ネットのような役割を果たします。あなたが信頼したものだけが動作することを許可するのです。

CSPを導入するための2つの一般的なアプローチ

現在、CSPを設定するには主に2つの方法があります。それぞれのサーバー環境に合わせて最適な方を選んでください。

1. HTMLにMetaタグを挿入する

この方法は非常に手軽です。Webページの<head>セクションに1行のコードを追加するだけで完了します。

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://apis.google.com;">

2. HTTPヘッダーで直接設定する (Nginx/Apache)

これはプロ向けの職人技です。ブラウザがHTML内を探すのではなく、サーバーがデータを返す際にセキュリティ指示を能動的に送信します。HackerOneのレポートによると、XSSはバグバウンティ（報奨金）の総額の23%以上を占めています。サーバー層で設定することで、このリスクをより徹底的にコントロールできます。

メリットとデメリットの分析

皆さんが選びやすいように、それぞれの強みをクイックに分析してみましょう：

  • HTML Metaタグ:
    • メリット: 導入が早い、サーバーのルート権限が不要。レンタルサーバー（共有ホスト）を使っている方に最適。
    • デメリット: ページ数が多いと管理が困難。特に、違反をサーバーに報告するreport-uri機能をサポートしていません。
  • WebサーバーからのHTTPヘッダー:
    • メリット: 数行の設定でサイト全体に一括適用できる。CSPの高度な機能をすべてサポート。トランスポート層で機能するため、よりセキュア。
    • デメリット: システム設定ファイルの編集権限が必要。構文を間違えると、Google MapsやFacebook Pixelなどの重要なスクリプトまでブロックされてしまいます。

なぜ私はWebサーバーでの設定を優先するのか

個人的な経験から言うと、管理の集約性の観点からサーバー側での設定をお勧めします。新しい画像ドメインを追加する必要がある場合も、1箇所修正するだけで済みます。HTMLファイルを一つずつ探して更新する手間はありません。また、ヘッダー経由で送信することでHTMLのパース負荷が減り、Lighthouseでの監査結果もより「プロっぽく」見えます。

NginxとApacheでの設定実践

安全なCSPポリシーには、通常以下の基本ディレクティブが含まれます：

  • default-src 'self': 自ドメインからのみリソースをロード。
  • script-src 'self': 内部スクリプトの実行のみ許可。
  • img-src 'self' data:: 内部画像とbase64画像の許可。
  • style-src 'self' 'unsafe-inline': 内部CSSを許可（可能であればunsafe-inlineの使用は控えるべき）。

1. Nginxの設定

ドメインの設定ファイルを開き、serverブロックに以下の行を追加します：

server {
    listen 443 ssl;
    server_name itfromzero.com;

    # 標準的なCSP設定
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://www.google-analytics.com; img-src 'self' https://images.unsplash.com; style-src 'self' 'unsafe-inline'; font-src 'self' https://fonts.gstatic.com;" always;
}

再起動前に構文チェックを忘れずに：

sudo nginx -t && sudo systemctl restart nginx

2. Apacheの設定

まず、sudo a2enmod headersコマンドでheadersモジュールが有効になっていることを確認してください。その後、.htaccessファイルに以下を追記します：

<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://www.google-analytics.com; img-src 'self'; style-src 'self';"
</IfModule>

デザイン崩れを防ぐための重要な注意点

CSPを有効にした途端、サイトが真っ白になったという話をよく聞きます。原因の多くは、CSPの設定が厳しすぎて、宣言し忘れた正当なスクリプトまでブロックしてしまったことです。コツは、まずContent-Security-Policy-Report-Onlyを使うことです。このモードはリソースをブロックせず、違反内容をコンソールにログ出力するだけなので、動作を確認しながら調整できます。

# Nginxでテスト
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self';";

CSPの整合性をチェックするツール

設定が終わったら、以下のツールを使って確実にチェックしましょう：

  1. F12 コンソール: 「CSP directive」に関連する赤文字のエラーが出ていれば、何かを誤ってブロックしています。
  2. Google CSP Evaluator: 作成したポリシーに脆弱性がないか診断してくれます。
  3. SecurityHeaders.com: URLを入力してセキュリティスコアを測定します。A+を目指しましょう。

セキュリティ対策は調整が多くて少し大変です。しかし、最初の手間を惜しんで、ある日突然Webサイトに勝手に広告リンクを貼られたり、裏で仮想通貨のマイニングをされたりするよりはずっとマシです。

Share:
Tags: