# Django 6.0.7 ドキュメント

# Django におけるセキュリティ

このドキュメントは、Django のセキュリティ機能の概要です。Django を利用したサイトを安全なものにするためのヒントを説明します。

Real-world security

Django's web security implementations have been designed with security for real-world applications in mind. Django is a general-purpose web application framework, and its defaults reflect this - they will not be the best solution for every particular case. Special cases deserve special attention to their needs.

Web security requires a multi-layered approach. Securing only a single vector does not make a site secure overall, nor does a single apparent weakness necessarily compromise the entire site. This should be borne in mind particularly when assessing individual points in security audits.

## ユーザーの入力は常にサニタイズしてください

Web アプリケーションのセキュリティにおける黄金律は、「ユーザーが制御できるデータを決して信用しないこと」です。そのため、アプリケーション内で使用する前に、すべてのユーザー入力は必ずサニタイズ（無害化）する必要があります。Django におけるユーザー入力の検証については、 フォームに関するドキュメント を参照してください。

## Cross-site scripting (XSS) protection

In a cross-site scripting attack, malicious code in the form of a client-side script is injected into another user's web browser, where it will be executed.

This is typically done by:

- storing the malicious script in the database where it will be retrieved and presented to other users in their browsers, or

- getting users to click a link which will cause the attacker's JavaScript to be executed by the user's browser.

Cross-site scripting attacks can originate from any untrusted source of data, including cookies or web services, if the data are not adequately sanitized before being published in a page.

Django templates provide protection against the majority of cross-site scripting attacks by automatically escaping characters that represent a risk (that is, HTML characters that could be interpreted by the browser to malicious effect are instead safely displayed).

However, the extent of this protection and its limitations should be understood.

Ambiguity between the developer's intention and how the browser interprets HTML can expose the client to unintended code execution. Suppose that a developer creates:

    <style class={{ var }}>...</style>

where `var` is expected to contain something like `'class1'`. If `var` were set to `'class1 onmouseover=javascript:func()'` though, this could result in unauthorized JavaScript execution due to differences in how browsers will interpret this imperfect HTML.

Explicit template design, in which the quotes are not left to the variable to provide:

    <style class="{{ var }}">...</style>

would eliminate this possibility.

It is also important to be particularly careful when using the `is_safe` attribute with custom template tags, the `safe` template tag, `mark_safe`, and when autoescape is turned off.

Django's built-in escaping is intended to protect HTML output. If you are using the template system to output something other than HTML, the characters and strings that require escaping might be entirely different.

Additionally, be very careful when storing HTML in the database, especially when that HTML is retrieved and displayed. Unless the HTML is guaranteed to come from a trusted source - user input is not a trusted source - stored HTML should be checked and sanitized, preferably on input as well as output.

## Cross-site request forgery (CSRF) protection

CSRF 攻撃は悪意ある利用者が、あるユーザーが自身で持っている情報や承認を用いずに、そのユーザーの認証情報での処理を発生させてしまう攻撃です。

Django は大半の CSRF 攻撃に対応したビルトインの防御機構を備え、適切な所で 有効化して利用できます 。しかしながら、いかなる緩和策にも制限が存在します。たとえば、CSRF モジュールをグローバルにあるいは特定のビューだけ無効化できます。これは自身が何をしているのか理解している場合のみ行うべきです。もしあなたのサイト内に管理対象外のサブドメインが存在すればそこにも 制限 が存在します。

CSRF 対策 は各 POST リクエスト内の秘密情報を確認することで機能します。悪意あるユーザーは、フォームの POST を別のログイン中のユーザーが気づかない間に「リプレイ」して、フォームを送信させようとします。これを実行するには秘密情報を知っている必要がありますが、秘密情報は（クッキーを用いて）ユーザーごとに固有なので、簡単に取得することはできません。これにより、フォームの POST の「リプレイ」を防ぐことができます。

HTTPS でデプロイした場合、`CsrfViewMiddleware` は HTTP referer ヘッダが (サブドメインとポートを含め) 同一オリジンの URL にセットされているかをチェックします。HTTPS では強化されたセキュリティを利用できるため、可能な限り安全でないコネクションのリクエストを転送したり、サポートされたブラウザでは HSTS を使用するなどして HTTPS コネクションを使用することが不可欠です。

どうしても必要という場合を除いて、 `csrf_exempt` デコレータでビューをマークする際には十分注意してください。

## SQL injectionへの防御

SQL injectionは、悪意ある攻撃者がデータベース任意のSQLコードを実行する攻撃です。これによって、レコードが削除されたり、情報が漏洩する可能性があります。

Djangoのクエリセットは、クエリのパラメータ化によってクエリを構成するため、SQL injectionから守られています。クエリのSQLコードはそのクエリのパラメータとは独立に定義されています。パラメータはユーザが指定するものも有り、安全ではないので、低レイヤのデータベースドライバーによってエスケープされます。

Djangoは開発者に、素のクエリを実行する または カスタムSQLを実行する 力も与えています。これらの機能は慎重に使用すべきであり、ユーザーが制御できるパラメータを適切にエスケープすることを常に注意すべきです。さらに、`extra()` や `RawSQL` を使用する際には注意が必要です。

## クリックジャッキング (Clickjacking) に対する防御

クリックジャッキング (Clickjacking) は、悪意のあるサイトが他のサイトをフレームの中に表示するタイプの攻撃です。攻撃の結果、疑いのないユーザーが騙されてターゲットのサイトに対して意図しない操作を行ってしまいます。

Djangoは クリックジャッキング保護 の仕組みを `X-Frame-Options ミドルウェア` で提供しています。サポートしているブラウザではサイトをフレーム内で描画しないようにします。この保護はビュー単位で無効化できます。あるいは、固定的にヘッダーの値を送信できます。

サードパーティのサイト上でページをフレーム内に表示する必要がないか、もし合ったとしてもごく少数のセクションしかないようなあらゆるサイトは、このミドルウェアを使用することを強く推奨します。

## SSL/HTTPS

セキュリティの観点から、サイトを HTTPS の下でデプロイするのは常に良い選択です。HTTPS がなければ、悪意のあるネットワークユーザーが、クライアント・サーバー間で通信される認証情報やその他あらゆる情報を盗み見たり、場合によっては、積極的な ネットワーク攻撃者がどちらの方向でもデータ書き換えが可能になってしまいます。

HTTPS による保護をサーバー上で有効にするためには、多少の追加作業が必要になります:

- 必要な場合は、関連する注意点を完全に理解した上で、`SECURE_PROXY_SSL_HEADER` をセットしてください。この設定に失敗すると、CSRF の脆弱性の原因となり、大変な危険につながりかねません！

- `SECURE_SSL_REDIRECT` を `True` にセットして、HTTP によるリクエストが HTTPS にリダイレクトされるようにしてください。

  `SECURE_PROXY_SSL_HEADER` の注意点を確認してください。リバースプロキシの場合、メインのウェブサーバーを HTTPS にリダイレクトするよう設定した方が簡単で安全かもしれません。

- '安全な' クッキーを使用してください。

  ブラウザが最初 HTTP で通信した場合 (これはブラウザのデフォルトの動作です)、既存のクッキーが誰でも見える状態になっている可能性があります。そのため、`SESSION_COOKIE_SECURE` と `CSRF_COOKIE_SECURE` を `True` にセットする必要があります。これにより、ブラウザは HTTPS コネクションによるクッキーを送信するようになります。これは、セッションが HTTP では動作せず、 CSRF 保護が HTTP によって受け入れられたあらゆる POST データを防止することを意味します (ただし、HTTP 通信を HTTPS にリダイレクトするよう設定しておけば問題ありません)。

- HTTP Strict Transport Security (HSTS) を使用してください。

  HSTS は HTTP ヘッダで、特定のサイトに対する以降のコネクションが常に HTTPS を使うことをブラウザに伝えるものです。HTTP から HTTPS にリクエストをリダイレクトさせることと合わせて、コネクションが 1 つ成功したときに提供される SSL の安全性を担保します。 HSTS は、`SECURE_HSTS_SECONDS`、`SECURE_HSTS_INCLUDE_SUBDOMAINS`, と `SECURE_HSTS_PRELOAD`、もしくはウェブサーバ上のどれかで設定されます。

## Host ヘッダーの検証

Django uses the `Host` header provided by the client to construct URLs in certain cases. While these values are sanitized to prevent cross-site scripting attacks, a fake `Host` value can be used for cross-site request forgery, cache poisoning attacks, and poisoning links in emails.

Because even seemingly-secure web server configurations are susceptible to fake `Host` headers, Django validates `Host` headers against the `ALLOWED_HOSTS` setting in the `django.http.HttpRequest.get_host()` method.

This validation only applies via `get_host()`; if your code accesses the `Host` header directly from `request.META` you are bypassing this security protection.

より詳しい情報については、`ALLOWED_HOSTS` ドキュメントをご覧ください。

警告

以前のドキュメントでは、外部から渡される `Host` ヘッダーを検証して正しい値にするようにウェブサーバーを設定することを推奨していました。これはまだ推奨されますが、多くの一般的なウェブサーバーは `Host` ヘッダーを正しく検証するように設定できません。例えば、Apacheがそのように設定されたとしても、あなたのDjangoサイトが `ServerName` に設定された非デフォルトの仮想ホストを扱うようにApacheに設定された場合、その仮想ホスト名に一致するような偽の `Host` ヘッダーを与えたHTTPリクエストを作れます。したがって、ウェブサーバー設定にたよるだけでなく、Djangoの `ALLOWED_HOSTS` に明示的に設定する必要があります。

さらに、Djangoでは `X-Forwarded-Host` ヘッダーのサポートを使いたければ ( `USE_X_FORWARDED_HOST` 設定で)明示的に有効にする必要があります。

## リファラ ポリシー

ブラウザは `Referer` ヘッダーを、ユーザーがどのようにしてそのサイトにたどり着いたかについての情報をサイトに送信する手段として使用します。 Referrer Policy を設定することで、どのような状況で `Referer` ヘッダが設定されるかを制限し、ユーザーのプライバシーを守ることができます。詳しくは セキュリティミドルウェアのリファレンス のリファラポリシーのセクションを参照してください。

## クロスオリジン・オープナー・ポリシー

クロスオリジンオープナーポリシー（COOP）ヘッダーは、ブラウザがトップレベルウィンドウを他のドキュメントから隔離し、異なるコンテキストグループに配置することを可能にします。これにより、それらがトップレベルウィンドウと直接的にやり取りすることができなくなります。COOPで保護されたドキュメントがクロスオリジンのポップアップウィンドウを開いた場合、ポップアップの `window.opener` プロパティは `null` になります。COOPはクロスオリジン攻撃から保護します。詳細については、 セキュリティミドルウェアリファレンスのクロスオリジンオープナーポリシーのセクション を参照してください。

## セッションのセキュリティ

CSRF limitation が、信頼できないユーザがサブドメインにアクセスできないようにサイトを配置することを要求しているのと同様に、 `django.contrib.sessions` にも制限があります。詳細は セッション・トピックガイドのセキュリティに関するセクション を参照してください。

## ユーザーがアップロードしたコンテンツ

注釈

以下に説明する問題を回避するには クラウドサービスやCDNから静的ファイルを配信する ことを検討してください。

- If your site accepts file uploads, it is strongly advised that you limit these uploads in your web server configuration to a reasonable size in order to prevent denial of service (DOS) attacks. In Apache, this can be easily set using the LimitRequestBody directive. You should not rely solely on `DATA_UPLOAD_MAX_MEMORY_SIZE` nor `FILE_UPLOAD_MAX_MEMORY_SIZE`.

- 独自の静的ファイルを提供している場合は、Apache の `mod_php` のような、静的ファイルをコードとして実行するハンドラが無効になっていることを確認してください。特別に細工されたファイルをアップロードしてリクエストすることで、ユーザが任意のコードを実行できるようになるのは望ましくありません。

- Django のメディアアップロード処理には、セキュリティのベストプラクティスに従わない方法でメディアが提供された場合、いくつかの脆弱性があります。具体的には、有効な PNG ヘッダの後に悪意のある HTML が続く場合、HTML ファイルを画像としてアップロードできます。このファイルは、 Django が `ImageField` の画像処理 (Pillow) に使っているライブラリの検証を通過します。このファイルがユーザに表示されるとき、 Web サーバの種類や設定によっては HTML として表示されるかもしれません。

  フレームワークレベルですべてのユーザーがアップロードしたファイルの内容を安全に検証するための完璧な技術的な解決策はありません。ただし、これらの攻撃を緩和できるいくつかの手順があります:

  1. ある種の攻撃は、ユーザがアップロードしたコンテンツを常に異なるトップレベルまたはセカンドレベルドメインから提供することで防ぐことができます。これにより、クロスサイトスクリプティングのような same-origin policy の保護によってブロックされる攻撃を防ぐことができます。例えば、あなたのサイトが `example.com` で運営されている場合、アップロードされたコンテンツ（`MEDIA_URL` 設定）は `usercontent-example.com` のようなドメインから提供されることが望ましいです。 `usercontent.example.com` のようなサブドメインからコンテンツを提供するだけでは十分ではありません。

  2. さらに、アプリケーションは、ユーザーがアップロードしたファイルに対して許可されるファイル拡張子のリストを定義し、そのようなファイルのみを提供するように Web サーバーを設定することもできます。

## Form Submissions

- Form submissions containing files are not limited by `DATA_UPLOAD_MAX_MEMORY_SIZE`. Under ASGI, the entire request may be spooled to disk before any file size validation is performed. It is strongly advised that you limit the maximum request body size in your web server configuration to prevent denial of service (DOS) attacks.

## Content Security Policy

New in Django 6.0.

Content Security Policy (CSP) is a browser security mechanism that helps protect web applications against attacks such as cross-site scripting (XSS) and other content injection attacks.

CSP allows web applications to define which sources of content are trusted, instructing the browser to load, execute, or render resources only from those sources. This effectively creates an allowlist of content origins, reducing the risk of malicious code execution.

Key benefits of enabling CSP include:

1. Mitigating XSS attacks by blocking inline scripts and restricting external script loading.

2. Controlling which external resources (e.g., images, fonts, stylesheets) can be loaded.

3. Preventing unwanted framing of your site to protect against clickjacking.

4. Reporting violations to a specified endpoint, enabling monitoring and debugging.

For configuration instructions, see the Using CSP documentation, and refer to the CSP overview for details on directives and settings.

### Limitations and considerations

While CSP is a powerful security mechanism, it's important to understand its limitations and implications, particularly when used in Django:

- Policy exclusion risks: Avoid excluding specific paths or responses from CSP protection. Due to the browser’s same-origin policy, a vulnerability on an unprotected page (e.g., one allowing arbitrary script injection) may be leveraged to attack protected pages. Excluding any route can significantly weaken the site's overall CSP protection.

- Performance overhead: Although typically negligible, CSP adds some processing overhead. Nonce generation involves secure randomness for each applicable request. For high-traffic applications or resource-constrained environments, measure the performance impact accordingly.

- Browser support: While CSP Levels 1 and 2 are widely supported, newer directives (CSP Level 3+) or complex policy behaviors may vary across browsers. Test your policy across the environments you intend to support.

Despite these limitations, CSP remains an important and recommended security layer for web applications. Understanding its constraints will help you design a more effective and reliable deployment.

## その他のセキュリティトピック

Django は、「箱から出してすぐに」優れたセキュリティ保護を提供しますが、アプリケーションを適切にデプロイし、Web サーバやオペレーティングシステム、その他のコンポーネントのセキュリティ保護を利用することが重要です。

- PythonコードがWebサーバのルートの外にあることを確認してください。こうすることで、Pythonコードが誤ってプレーンテキストとして提供されない（あるいは誤って実行されない）ようになります。

- ユーザがアップロードしたファイル には注意してください。

- Djangoはユーザーを認証するためのリクエストの制限を行いません。認証システムへの総当たり攻撃から保護するためには、これらのリクエストを制限するためのDjangoプラグインやWebサーバーモジュールを導入することを検討してください。

- あなたの `SECRET_KEY` と `SECRET_KEY_FALLBACKS` を秘密にしておいてください。

- ファイアウォールを使用して、キャッシュシステムとデータベースへのアクセスを制限することをお勧めします。

- Open Web Application Security Project (OWASP) の Top 10 list を見てください。OWASP は、Web アプリケーションによくある脆弱性をいくつか挙げています。Django には、いくつかの問題に対処するためのツールがありますが、それ以外はプロジェクトの設計で考慮する必要があります。

- Mozilla は web security に関する様々なトピックについて議論しています。彼らのページには、どのようなシステムにも適用できるセキュリティの原則も含まれています。