Content-Security-Policy

Provides Content-Security-Policy HTTP headers to protect against XSS and other code injection attacks by controlling which resources can be loaded by the browser.

csp
18,854 sites
93
drupal.org

インストール

Drupal 11, 10 v2.2.2
composer require 'drupal/csp:^2.2'

概要

Content-Security-Policy(CSP)モジュールは、DrupalサイトがContent-Security-Policy HTTPヘッダーを送信できるようにします。これは、クロスサイトスクリプティング(XSS)、クリックジャッキング、その他のコードインジェクション攻撃を防ぐための強力なセキュリティメカニズムです。CSPにより、サイト管理者はスクリプト、スタイルシート、画像、フォント、その他のリソースの信頼できるソースを指定できます。

このモジュールは、Report-OnlyポリシーとEnforcedポリシーの両方を設定するための包括的な管理インターフェースを提供し、すべての標準CSPディレクティブをサポートしています。Drupalライブラリで定義された外部リソースを自動検出し、ポリシーに追加するため、手動設定の手間が軽減されます。また、特定のインラインスクリプトやスタイルを許可しながら他をブロックするためのnonceとハッシュのサポートも含まれています。

開発者向けには、CSPポリシーをプログラムで変更するためのサービスとイベント、およびカスタムレポートハンドラーを実装するためのプラグインシステムを提供しています。テーマは専用のalter hookを使用して必要に応じてポリシーを変更できます。

Features

  • デュアルポリシーサポート:Report-OnlyとEnforcedのContent-Security-Policyヘッダーを独立して設定可能
  • 包括的なディレクティブサポート:default-src、script-src、style-src、img-src、font-src、connect-src、frame-src、frame-ancestors、form-action、base-uri、object-src、worker-src、manifest-src、media-src、prefetch-src、sandbox、webrtc、trusted-typesなど、すべてのCSP3ディレクティブを設定可能
  • 自動ライブラリ検出:有効なすべてのモジュールとテーマをスキャンし、ライブラリ定義から外部スクリプトとスタイルシートのソースを自動的に含める
  • nonceサポート:セキュリティを維持しながら特定のインラインスクリプトとスタイルを許可するための、リクエストごとの暗号学的nonce生成
  • ハッシュサポート:特定のインラインコードをホワイトリストに登録するためのSHA-256、SHA-384、SHA-512ハッシュの計算と組み込み
  • 柔軟なソース設定:ディレクティブごとにベースポリシー(self、none、any)を設定し、追加の許可ソースを指定可能
  • キーワードフラグサポート:適用可能なディレクティブに対して'unsafe-inline'、'unsafe-eval'、'unsafe-hashes'、'report-sample'、'wasm-unsafe-eval'、'inline-speculation-rules'などのフラグを有効化
  • プラグイン対応レポートシステム:カスタムURIエンドポイントとReport-URI.com統合の組み込みサポート、およびカスタムレポートハンドラー用のプラグインアーキテクチャ
  • CKEditor5統合:ページにCKEditor5が存在する場合、必要な例外を自動的に追加
  • ポリシー最適化:冗長なソースを自動的に削減し、フォールバック値と一致するディレクティブを削除
  • Firefoxバグの回避策:default-srcにおけるnonce/ハッシュに関するFirefoxバグの回避策を含む
  • イベント駆動アーキテクチャ:CspEvents::POLICY_ALTERイベントにより、モジュールはポリシー送信前に変更可能
  • テーマhookサポート:hook_csp_policy_alterによりテーマがポリシーをカスタマイズ可能
  • render element統合:CSPソース、nonce、ハッシュをrender elementに直接アタッチ可能

Use Cases

Basic XSS Protection

Enable both Report-Only and Enforce policies with 'self' as the base for script-src and style-src. This prevents loading of external scripts and styles that could be injected by attackers. Use the Report-Only policy first to identify any legitimate external resources that need to be allowed.

Preventing Clickjacking

Configure the frame-ancestors directive with 'self' or 'none' to prevent your pages from being embedded in frames on other sites. This protects against clickjacking attacks where attackers overlay transparent iframes over legitimate content.

Allowing CDN Resources

Add CDN hostnames (e.g., 'https://cdn.example.com') to the appropriate directives (script-src, style-src, font-src, img-src) to allow resources from trusted CDNs while blocking unknown sources. The module automatically detects many CDN sources from Drupal library definitions.

Using Nonces for Inline Scripts

For modules that need to add inline scripts, use the csp.policy_helper service to add nonces. Attach 'csp_nonce' to render elements with a fallback value. The nonce is automatically added to script-src-elem and the header, allowing specific inline scripts while blocking others.

Mixed Content Upgrade

Enable 'upgrade-insecure-requests' in the Enforce policy to automatically upgrade HTTP requests to HTTPS, helping with HTTPS migration without breaking resources referenced with HTTP URLs.

Third-Party Widget Integration

When embedding third-party widgets (Google Maps, social media embeds, etc.), add the required domains to frame-src, script-src, and style-src directives. Start with Report-Only mode to discover all required sources, then move to Enforce mode.

Implementing Trusted Types

Enable trusted-types and require-trusted-types-for directives to prevent DOM-based XSS by requiring the use of Trusted Types API for dangerous DOM manipulation sinks. This is an advanced feature for applications with complex JavaScript.

Tips

  • Always start with Report-Only mode to discover required sources before enforcing the policy
  • Use the Report-URI.com Wizard feature during development to easily build your policy
  • The 'report-sample' flag helps identify which inline scripts or styles are causing violations
  • External sources defined in *.libraries.yml files are automatically detected - check if libraries are properly defined before manually adding sources
  • Use browser developer tools (Console and Network tabs) to identify CSP violations
  • The frame-ancestors directive replaces the older X-Frame-Options header for clickjacking protection
  • Consider enabling 'upgrade-insecure-requests' when migrating to HTTPS to avoid mixed content issues
  • When using nonces, always provide a fallback value for browsers that may not support nonces
  • Directives marked with 'auto' in the admin interface have sources automatically detected from libraries

Technical Details

Admin Pages 1
Content Security Policy /admin/config/system/csp

Configure Content-Security-Policy headers for your site with support for both Report-Only and Enforced policies. The page uses vertical tabs to separate policy configuration.

権限 1
Administer Content Security Policy

Allows users to configure Content-Security-Policy headers. This permission is restricted and should only be granted to trusted administrators.

Hooks 1
hook_csp_policy_alter

Allows themes to alter the CSP policy for the current response. This hook is only invoked for themes; modules should use the CspEvents::POLICY_ALTER event instead.

Troubleshooting 6
CSP violations blocking legitimate functionality

Start with Report-Only mode enabled and Enforce disabled. Monitor browser console and reporting endpoint for violations. Add necessary sources to the appropriate directives. Only enable Enforce mode after all legitimate sources are allowed.

CKEditor5 not working properly

The module automatically adds 'unsafe-inline' for CKEditor5 when detected. Ensure the module is detecting CKEditor5 correctly. If issues persist, manually add 'unsafe-inline' to style-src directives.

External library scripts being blocked

Check if the library is defined in a *.libraries.yml file with the external URL. The module auto-detects these. If not auto-detected, manually add the host to script-src-elem and script-src directives.

Inline styles being blocked

If you cannot avoid inline styles, add 'unsafe-inline' to style-src directives. For better security, use the csp.policy_helper service to add hashes for specific inline styles.

script-src-attr or style-src-attr directive configured without fallback

The module will warn if *-attr or *-elem sub-directives are enabled without a corresponding fallback directive (script-src, style-src, or default-src). Enable the parent directive to ensure compatibility with browsers that don't support sub-directives.

No CSP header being sent

Check that at least one policy (Report-Only or Enforce) is enabled in configuration. Verify the user has permission to access the page and that caching is not interfering. Check that no other module or web server is removing the header.

Security Notes 6
  • The 'administer csp configuration' permission should only be granted to trusted administrators as misconfiguration can either break site functionality or weaken security
  • Avoid using 'unsafe-inline' and 'unsafe-eval' in production unless absolutely necessary, as they significantly weaken CSP protection
  • The 'strict-dynamic' keyword is not configurable through the UI as it requires hash or nonce implementation in application code
  • Hash sources in script-src or style-src may block functionality that relies on inline code - test thoroughly
  • The Report-Only header allows monitoring violations without blocking them - use this to develop your policy safely
  • CSP is a defense-in-depth measure and should not be the only security mechanism protecting your site