CSP が XSS 攻撃を防げるよう設定されているか確認する方法

12 min 19 views

Webサイトを運営している皆さん、XSS攻撃などのセキュリティ脅威にさらされていませんか？近年、Webアプリケーションへの攻撃は増加傾向にあり、特にクロスサイトスクリプティング（XSS）攻撃は深刻な脅威となっています。

そんな中、コンテンツセキュリティポリシー（CSP）は、あなたのWebサイトを守るための強力な武器となります。この記事では、CSPがXSS攻撃を防ぐための設定方法から確認方法まで、実践的で包括的に解説していきます。

特に、表示速度の改善という観点からも、CSPの適切な設定はセキュリティ向上だけでなく、サイトパフォーマンスの最適化にも繋がります。これは、弊社landinghubでも重要視している点です。

目次

CSPとは何か？基本概念を理解する

CSPの定義と概要

CSP（Content Security Policy）は、Webアプリケーションのセキュリティを強化するための仕組みです。簡単に言うと、ブラウザに対して「どのリソースを信頼して実行してもよいか」を指示する仕組みのことなんです。

これにより、悪意のあるコードの実行を防ぎ、クロスサイトスクリプティング（XSS）攻撃などのセキュリティ脅威から保護することができます。CSPは、Webサーバーからブラウザに送信されるHTTPレスポンスヘッダーに記述されます。

XSS攻撃とは何か？

XSS攻撃について詳しく見ていきましょう。XSS攻撃には大きく分けて3つの種類があります：

1. 反射型XSS 悪意のあるスクリプトを含むリンクを被害者に踏ませることで発生します。攻撃者が用意したURLに悪意のあるスクリプトが含まれており、そのURLをクリックしたユーザーのブラウザで実行されます。

2. 蓄積型XSS 脆弱なWebアプリケーションに悪意のあるスクリプトを投稿し、それを他のユーザーが閲覧することで発生します。掲示板やブログのコメント欄などでよく見られます。

3. DOM Based XSS JavaScriptのコードの脆弱性を突いて、ブラウザ上で悪意のあるスクリプトを実行させる手法です。

XSS攻撃の影響は深刻で、以下のような被害が発生する可能性があります：

  • セッションID等を持たせているHttpOnly属性のないCookieの取得
  • Web Storage内で持っているアクセストークン等の取得
  • 本来は存在しない情報の表示
  • 本物サイト上に偽のページが表示される
  • フィッシング詐欺による重要情報の漏洩

CSPの基本的な仕組みとメリット

CSPの動作原理

CSPは、以下のような指示をブラウザに与えます：

  • スクリプトの実行元を制限する
  • スタイルシートの読み込み元を制限する
  • 画像、フォント、動画などのリソースの取得元を制限する
  • フレームの読み込み元を制限する

これらの制限を設定することで、信頼できるドメインからのみコンテンツを取得し、不正なスクリプトの実行を防ぐことができます。CSPの設定は柔軟性が高く、Webサイトの要件に応じて適切なルールを定義できます。

CSP設定によるセキュリティ向上のメリット

CSPを適切に設定することで、以下のようなメリットが得られます：

1. XSS攻撃の大幅な軽減 信頼できないソースからのスクリプトの実行を防ぎ、XSS攻撃のリスクを大幅に減らすことができます。

2. データの漏洩防止 不正なスクリプトによる機密情報の窃取を防ぎます。

3. 開発効率の向上 CSPのレポート機能を活用すれば、ポリシー違反の発生をモニタリングし、問題の特定と修正を迅速に行うことができます。

4. 表示速度の改善 不要なリソースの読み込みを制限することで、サイトの表示速度向上にも貢献します。これはlandinghubのような高速表示を重視するプラットフォームでも重要な要素です。

CSPの主要なディレクティブ詳細解説

default-src – 基本設定の要

default-srcは、他のディレクティブが指定されていない場合のデフォルトの設定を指定するディレクティブです。すべてのリソースタイプに対する基本ルールを定義します。

default-src 'self';

この設定により、同一オリジンからのリソースのみを許可します。他のディレクティブで明示的に設定されていない場合、この設定が適用されます。

script-src – スクリプト実行の制御

script-srcは、JavaScript の読み込み元を制限するディレクティブで、XSS攻撃の防止に最も重要な役割を果たします。

基本的な設定例：

script-src 'self' https://trusted.com;

安全でない設定（避けるべき）：

script-src 'unsafe-inline';

unsafe-inlineは、イベントハンドラを含むすべてのインラインスクリプトの実行を許可してしまうため、穴のある設定と言えます。

より安全な設定：

script-src 'self' 'nonce-ランダムな値';

style-src と img-src – スタイルと画像の制御

style-srcはCSSの読み込み元を制限し、img-srcは画像の読み込み元を制限します。

style-src 'self' https://trusted-css.com;
img-src 'self' https://trusted-images.com data:;

data:を含めることで、Base64エンコードされた画像の使用も許可できます。

frame-ancestors と base-uri – フレーミング対策

frame-ancestorsは、ページをフレーム内に表示することを許可するドメインを指定します。クリックジャッキング攻撃の防止に重要です。

frame-ancestors 'self' https://trusted-framing.com;

base-uriは、相対パスの解決に使用される基準となるURLを制限します。

base-uri 'self';

object-src – プラグインコンテンツの制御

object-srcは、<object>、<embed>、<applet>要素の読み込みを制御します。Flashなどのプラグインコンテンツに対する制限です。

object-src 'none';

現在ではFlashなどのプラグインはほとんど使用されないため、'none'に設定することが推奨されます。

高度なCSP設定技術

nonce（ナンス）を使用した動的制御

nonceは、ランダムな値を生成してスクリプトやスタイルに付与し、CSPでその値を指定することで許可する仕組みです。

サーバーサイドでの実装例（Express.js）：

Copyconst app = express();

app.get('/', function(request, response) {
  // リクエストごとに新しいランダムなnonce値を生成
  const nonce = crypto.randomBytes(16).toString("base64");
  
  // strictなnonce ベースのCSPレスポンスヘッダーを設定
  const csp = `script-src 'nonce-${nonce}' 'strict-dynamic'; object-src 'none'; base-uri 'none';`;
  response.set("Content-Security-Policy", csp);
  
  // アプリケーション内のすべての<script>タグにnonce属性を設定
  response.render(template, { nonce: nonce });
});

HTML側での使用例：

Copy<script nonce="ランダムな値">
  // 許可されたスクリプト
  alert('This is allowed');
</script>

hash を使用した静的制御

hashは、スクリプトやスタイルの内容をハッシュ化し、CSPでそのハッシュ値を指定することで許可する方法です。

script-src 'sha256-ハッシュ値';

この方法は、スクリプトの内容が変更されない静的なケースに適しています。

strict-dynamic による信頼の継承

strict-dynamicは、実行を許可したスクリプトから読み込まれたスクリプトも同様に実行を許可する仕組みです。親のスクリプトが得た信頼を、子に継承することを許可します。

script-src 'nonce-12345678' 'strict-dynamic';

この設定により、nonceで許可されたスクリプトが動的に生成する子スクリプトも実行が許可されます。

実践的なCSP設定例

基本的なCSP設定

多くのWebサイトに適用可能な基本的な設定例です：

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https:; connect-src 'self' https:; frame-ancestors 'self'; base-uri 'self'; object-src 'none';

厳格なCSP設定（Strict CSP）

Googleが推奨する厳格なCSP設定です：

Content-Security-Policy: script-src 'nonce-{RANDOM}' 'strict-dynamic' 'unsafe-inline' https:; object-src 'none'; base-uri 'none'; report-uri https://reporting.example.com;

段階的導入のためのReport-Only設定

本格導入前のテスト段階で使用する設定です：

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

CSP設定の実装方法

HTTPヘッダーでの設定（推奨）

Apache の場合：

CopyHeader always set Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.com;"

Nginx の場合：

Copyadd_header Content-Security-Policy "default-src 'self'; script-src 'self' https://trusted.com;" always;

HTMLメタタグでの設定

HTTPヘッダーでの設定が困難な場合は、HTMLメタタグでも設定可能です：

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

ただし、frame-ancestorsやsandboxなど、一部のディレクティブはメタタグでは機能しません。

CSP設定の確認方法

ブラウザ開発者ツールを使用した確認

Chrome DevTools での確認手順：

  1. F12キーで開発者ツールを開く
  2. 「Console」タブをクリック
  3. ページを読み込み直す
  4. CSP違反があれば、以下のようなメッセージが表示されます：
Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'"

Firefox の場合：

Web Consoleに違反情報が表示されます。CSPの設定状況や違反の詳細を確認できます。

オンラインツールを使用した確認

1. CSP Evaluator Googleが提供するCSP評価ツールです。 URL: https://csp-evaluator.withgoogle.com/

このツールでは、CSP設定の安全性を評価し、改善提案を受けることができます。

2. Lighthouse での確認 Lighthouse v7.3.0以降では、CSPによるXSS対策の効果を評価する機能があります。

Copylighthouse --preset=experimental https://example.com

CSP違反レポートの活用

CSP違反が発生した際のレポートを収集・分析することで、設定の改善を行えます。

レポートエンドポイントの設定：

Content-Security-Policy: default-src 'self'; report-uri https://example.com/csp-reports;

受信するレポートの例：

Copy{
  "csp-report": {
    "document-uri": "https://example.com/",
    "referrer": "",
    "violated-directive": "script-src 'self'",
    "effective-directive": "script-src",
    "original-policy": "default-src 'self'; script-src 'self'",
    "blocked-uri": "https://malicious.com/evil.js",
    "status-code": 200
  }
}

表示速度改善とCSPの関係

CSPの適切な設定は、セキュリティ向上だけでなく、サイトの表示速度改善にも大きく貢献します。

リソース読み込みの最適化

CSPによって不要なリソースの読み込みを制限することで、以下の効果が期待できます：

  • 帯域幅の節約: 不正なリソースの読み込みを防ぎ、必要なリソースのみを取得
  • レンダリングの高速化: 信頼できるリソースのみを処理するため、ブラウザの負荷が軽減
  • キャッシュ効率の向上: 明確に定義されたリソースポリシーにより、キャッシュ戦略が最適化

パフォーマンス監視との連携

landinghubのような高速表示を重視するプラットフォームでは、CSPの設定とパフォーマンス監視を組み合わせることで、より効果的な最適化が可能です。

具体的な改善例：

  1. 外部リソースの制限: 信頼できるCDNからのみリソースを読み込むことで、読み込み時間を短縮
  2. インラインスクリプトの制御: nonceを使用してインラインスクリプトを適切に管理し、初期表示速度を向上
  3. フォントの最適化: font-srcディレクティブによる適切なフォント読み込み制御

実際のXSS攻撃例とCSP対策

実際の攻撃シナリオ

以下は、実際のXSS攻撃とその対策例です：

攻撃者が投稿する悪意のあるコード：

Copy<img src="invalid-image" onerror="alert(localStorage.getItem('accessToken'))">

このコードは、画像の読み込みに失敗した場合にJavaScriptを実行し、LocalStorageからアクセストークンを窃取しようとします。

CSP設定による対策

対策前（脆弱な状態）：

Copy<!-- CSP設定なし -->
<div id="user-content">
  <img src="invalid-image" onerror="alert(localStorage.getItem('accessToken'))">
</div>

結果：アクセストークンが表示されてしまいます。

対策後（CSP設定済み）：

Copy<meta http-equiv="Content-Security-Policy" content="script-src 'self'; img-src 'self'; connect-src https://api.example.com">
<div id="user-content">
  <img src="invalid-image" onerror="alert(localStorage.getItem('accessToken'))">
</div>

結果：以下のエラーが表示され、攻撃が阻止されます。

Refused to execute inline event handler because it violates the following Content Security Policy directive: "script-src 'self'"

CSP設定時の注意点とベストプラクティス

段階的導入のススメ

CSPの導入は、以下の段階的なアプローチが推奨されます：

1. 現状調査フェーズ

  • 現在のサイトで使用されているリソースの棚卸し
  • 外部ドメインからの読み込み状況の確認

2. Report-Only フェーズ

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

3. 段階的制限フェーズ まずは緩い制限から始めて、徐々に厳格化していきます。

4. 本格運用フェーズ 十分なテストを経て、本格的なCSP設定を適用します。

互換性の確保

CSP設定時は、以下の点に注意が必要です：

ブラウザサポートの確認

  • 古いブラウザでのCSP対応状況を確認
  • 必要に応じて、フォールバック設定を用意

サードパーティライブラリとの互換性

  • Google Analytics、広告タグなどの外部サービスとの互換性確認
  • 必要に応じて、ホワイトリストに追加

継続的な監視と改善

CSPの設定は、一度行えば終わりではありません：

定期的な見直し

  • 新しい脅威に対応するため、定期的に設定を見直し
  • サイトの機能追加に伴う設定の更新

レポートの分析

  • 違反レポートを定期的に分析し、不正な攻撃の検知
  • 正当なリソースが誤ってブロックされていないかの確認

高度なCSP活用術

SRI（Subresource Integrity）との連携

CSPとSRI（Subresource Integrity）を組み合わせることで、外部リソースの整合性を検証できます：

Copy<script src="https://example.com/script.js" 
        integrity="sha256-ハッシュ値" 
        crossorigin="anonymous"></script>

CSP設定：

Content-Security-Policy: script-src 'self' https://example.com; require-sri-for script;

Trusted Types との組み合わせ

DOM Based XSS対策により効果的な設定：

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types myPolicy;

これにより、信頼できるタイプのみがDOM操作を行えるようになります。

動的CSP生成

大規模なアプリケーションでは、動的にCSPを生成することも有効です：

Copy// Node.js での例
function generateCSP(userPermissions) {
  let csp = "default-src 'self';";
  
  if (userPermissions.includes('analytics')) {
    csp += " script-src 'self' https://google-analytics.com;";
  }
  
  if (userPermissions.includes('social')) {
    csp += " frame-src 'self' https://facebook.com https://twitter.com;";
  }
  
  return csp;
}

トラブルシューティング

よくある問題と解決方法

1. インラインスクリプトがブロックされる

問題：

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'"

解決方法：

Copy<!-- nonce を使用 -->
<script nonce="ランダムな値">
  // スクリプト内容
</script>

2. 外部リソースが読み込めない

問題：Google Fontsなどが読み込めない

解決方法：

Content-Security-Policy: font-src 'self' https://fonts.gstatic.com; style-src 'self' https://fonts.googleapis.com;

3. 画像が表示されない

問題：Data URIやBase64画像が表示されない

解決方法：

Content-Security-Policy: img-src 'self' data:;

デバッグ手法

1. ブラウザコンソールでの確認

  • F12 → Console タブで違反内容を確認
  • Network タブでブロックされたリソースを確認

2. 段階的な設定確認

Copy# curl でヘッダーを確認
curl -I https://example.com | grep -i content-security-policy

3. 自動化テスト

Copy// Puppeteer での CSP テスト例
const puppeteer = require('puppeteer');

async function testCSP() {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  
  const cspViolations = [];
  page.on('response', response => {
    if (response.url().includes('csp-report')) {
      cspViolations.push(response);
    }
  });
  
  await page.goto('https://example.com');
  
  console.log('CSP violations:', cspViolations.length);
  await browser.close();
}

まとめ

CSP（Content Security Policy）は、XSS攻撃からWebサイトを守るための強力なセキュリティ機能です。適切に設定することで、以下のような効果が期待できます：

主要なメリット

  1. XSS攻撃の大幅な軽減 – 悪意のあるスクリプトの実行を防止
  2. データ漏洩の防止 – 機密情報の不正な取得を阻止
  3. 表示速度の向上 – 不要なリソースの読み込みを制限
  4. 開発効率の向上 – 自動化された脅威検知とレポート機能

実装のポイント

  • 段階的導入 – Report-Onlyから始めて徐々に厳格化
  • 継続的監視 – 違反レポートの定期的な分析
  • 互換性確保 – サードパーティサービスとの適切な連携
  • パフォーマンス最適化 – セキュリティと表示速度の両立

今後の展望

CSPは今後も進化し続け、より高度なセキュリティ機能が追加されていくでしょう。Trusted TypesやSRIとの連携など、包括的なセキュリティ対策の一環として活用することが重要です。

特に、landinghubのような高速表示を重視するプラットフォームでは、CSPの適切な設定がセキュリティと表示速度の両方を向上させる重要な要素となります。

セキュリティは一朝一夕で完璧になるものではありません。 CSPの理解と適切な運用を通じて、より安全で高速なWebサイトを構築していきましょう。定期的な設定見直しと継続的な改善が、堅牢なWebアプリケーションを作り上げる鍵となるのです。

CSPの設定でお困りの際は、専門家のサポートを受けることも検討してみてください。適切なセキュリティ対策により、ユーザーに安心してサービスを利用していただける環境を提供できるはずです。

<PREV
「一部の要素にラベル要素が関連付けられています」エラーの原因と対処法｜PageSpeed Insights改善ガイド
NEXT>
「サポートを終了したAPIが使用されています」PageSpeed Insightsの警告対処法と表示速度改善の完全ガイド
関連記事

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です