---
title: "Django におけるセキュリティ"
version: 4.2
locale: ja
source: https://docs.djangoproject.com/ja/4.2/topics/security/
canonical: https://djangodocs.dev/ja/4.2/topics/security/
---
# Django におけるセキュリティ

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

## クロス・サイト・スクリプティング (XSS) の防御

XSS 攻撃はあるユーザーに対してクライアント用のスクリプトを別のユーザーのブラウザに読み込ませることを可能にしてしまいます。この攻撃は通常他のユーザーに対して選択・表示を行うデータベース内に悪意のあるスクリプトを保存させる、あるいは攻撃者の JavaScript がブラウザで実行されるリンクをユーザーにクリックさせることでなされます。しかしながら、XSS 攻撃はページを読み込む前に十分なサニタイズを行っていなければ、信頼できないクッキーやウェブ・サービスのようなデータが発生の原因となることがあります。

Django のテンプレートを用いる事で多数の XSS 攻撃に対抗することができます。しかしながら、それがどのような防御策が用意でき、またその利用に際する制限について知ることが重要になります。

Django は HTML に対して特に危険とみなされる [特定の文字列のエスケープ](/ja/4.2/ref/templates/language/#automatic-html-escaping) を行います。この防御によってユーザーは大半の悪意のある入力から守られますが、いつも簡単で容易に利用できる訳ではありません。たとえば、次に示す例では防御がなされません。

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

もし `var` の値が `'class1 onmouseover=javascript:func()'` にセットされた場合、不完全な HTML をそのブラウザがどのようにレンダリングするかによっては、許可されていない Javascript を実行させる事になります。(このケースであれば属性値のクオートを行えば対処できます)

カスタム・テンプレート・タグと共に `is_safe` を用いたり、 [`safe`](/ja/4.2/ref/templates/builtins/#std-templatefilter-safe) テンプレートタグや、 [`mark_safe`](/ja/4.2/ref/utils/#module-django.utils.safestring) の利用に加えてオートエスケープが無効化されている場合十分な注意を払う必要が有ります。

ここまでの内容に加えて、HTML 以外を出力するのにテンプレートシステムを利用している場合、完全に別のエスケープすべき文字や単語が存在するかもしれません。

HTML をデータベース内に収集、特にその HTML が選択・表示される場合は十分な注意を払う必要が有ります。

## クロス・サイト・リクエスト・フォージェリ(CSRF)の防御

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

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

[CSRFプロテクション](/ja/4.2/ref/csrf/#how-csrf-works) はそれぞれのPOSTリクエストのシークレットを検証することで動作します。これにより、悪意のあるユーザーがあなたのウェブサイトに対してフォームのPOSTを「再送信」することはできず、他のログイン済みユーザーは意識することなくフォームを送信することができます。悪意のあるユーザーはCookieを使用したユーザー固有のシークレットを知る必要があります。

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

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

## SQL injectionへの防御

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

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

Django開発者はまた、 [生のクエリ](/ja/4.2/topics/db/sql/#executing-raw-queries) を書くことや [custom SQL](/ja/4.2/topics/db/sql/#executing-custom-sql) を実行することができます。これらの手段は慎重に用いなければいけません。開発者は常に、ユーザがコントロールできるパラメータを適切にエスケープしなければなりません。加えて、extra()とRawSQLを使うときには警戒を忘れないようにしなければなりません。

## Clickjacking に対する防御

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

Djangoは [clickjacking保護](/ja/4.2/ref/clickjacking/#clickjacking-prevention) の仕組みを [`X-Frame-Options ミドルウェア`](/ja/4.2/ref/middleware/#django.middleware.clickjacking.XFrameOptionsMiddleware) で提供しています。サポートしているブラウザではサイトをフレーム内で描画しないようにします。この保護はビュー単位で無効化できます。あるいは、固定的にヘッダーの値を送信できます。

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

## SSL/HTTPS

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

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

- 必要な場合は、関連する注意点を完全に理解した上で、 [`SECURE_PROXY_SSL_HEADER`](/ja/4.2/ref/settings/#std-setting-SECURE_PROXY_SSL_HEADER) をセットしてください。この設定に失敗すると、 CSRF の脆弱性の原因となり、大変な危険につながりかねません!
- [`SECURE_SSL_REDIRECT`](/ja/4.2/ref/settings/#std-setting-SECURE_SSL_REDIRECT) を `True` にセットして、HTTP によるリクエストが HTTPS にリダイレクトされるようにしてください。

  [`SECURE_PROXY_SSL_HEADER`](/ja/4.2/ref/settings/#std-setting-SECURE_PROXY_SSL_HEADER) の注意点を確認してください。リバースプロキシの場合、メインのウェブサーバーを HTTPS にリダイレクトするよう設定した方が簡単で安全かもしれません。
- '安全な' クッキーを使用してください。

  ブラウザが最初 HTTP で通信した場合 (これはブラウザのデフォルトの動作です)、既存のクッキーが誰でも見える状態になっている可能性があります。そのため、[`SESSION_COOKIE_SECURE`](/ja/4.2/ref/settings/#std-setting-SESSION_COOKIE_SECURE) と [`CSRF_COOKIE_SECURE`](/ja/4.2/ref/settings/#std-setting-CSRF_COOKIE_SECURE) を `True` にセットする必要があります。これにより、ブラウザは HTTPS 接続によるクッキーを送信するようになります。これは、セッションが HTTP では動作せず、 CSRF 保護が HTTP によって受け入れられたあらゆる POST データを防止することを意味します (が、HTTP 通信を HTTPS にリダイレクトするよう設定しておけば問題ありません)。
- [HTTP Strict Transport Security](/ja/4.2/ref/middleware/#http-strict-transport-security) (HSTS) を使用してください。

  HSTS は HTTP ヘッダで、特定のサイトに対する以降の接続が常に HTTPS を使うことをブラウザに伝えるものです。HTTP から HTTPS にリクエストをリダイレクトさせることと合わせて、接続が 1 つ成功したときに提供される SSL の安全性を担保します。 HSTS は、[`SECURE_HSTS_SECONDS`](/ja/4.2/ref/settings/#std-setting-SECURE_HSTS_SECONDS)、[`SECURE_HSTS_INCLUDE_SUBDOMAINS`](/ja/4.2/ref/settings/#std-setting-SECURE_HSTS_INCLUDE_SUBDOMAINS), と [`SECURE_HSTS_PRELOAD`](/ja/4.2/ref/settings/#std-setting-SECURE_HSTS_PRELOAD)、もしくはウェブサーバ上のどれかで設定されます。

## Host ヘッダーの検証

Djangoはいくつかのケースで、URLを組み立てるためにクライアントから送られてきた `Host` ヘッダーを使用します。 `Host` ヘッダーの値は、クロス・サイト・スクリプティング (XSS) 攻撃を回避するためにサニタイズされますが、それでもまだニセの `Host` 値はクロス・サイト・リクエスト・フォージェリ (CSRF) やキャッシュポイズニング攻撃、Eメールアドレス内のリンクへのポイズニング等に使用されます。

一見安全なウェブサーバー設定であっても偽の `Host` ヘッダーの可能性が残るため、Djangoは [`django.http.HttpRequest.get_host()`](/ja/4.2/ref/request-response/#django.http.HttpRequest.get_host) メソッド内で `Host` ヘッダーの値を [`ALLOWED_HOSTS`](/ja/4.2/ref/settings/#std-setting-ALLOWED_HOSTS) 設定で検証します。

このヘッダの検証は [`get_host()`](/ja/4.2/ref/request-response/#django.http.HttpRequest.get_host) メソッドの実行時にのみ適用されます。もし `request.META` から直接 `Host` ヘッダにアクセスするコードを書いてしまうと、このセキュリティプロテクションを回避してしまうので注意してください。

より詳しい情報については、[`ALLOWED_HOSTS`](/ja/4.2/ref/settings/#std-setting-ALLOWED_HOSTS) ドキュメントをご覧ください。

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

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

## Referrer policy

Browsers use the `Referer` header as a way to send information to a site
about how users got there. By setting a *Referrer Policy* you can help to
protect the privacy of your users, restricting under which circumstances the
`Referer` header is set. See [the referrer policy section of the
security middleware reference](/ja/4.2/ref/middleware/#referrer-policy) for details.

## Cross-origin opener policy

The cross-origin opener policy (COOP) header allows browsers to isolate a
top-level window from other documents by putting them in a different context
group so that they cannot directly interact with the top-level window. If a
document protected by COOP opens a cross-origin popup window, the popup’s
`window.opener` property will be `null`. COOP protects against cross-origin
attacks. See [the cross-origin opener policy section of the security
middleware reference](/ja/4.2/ref/middleware/#cross-origin-opener-policy) for details.

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

Similar to the [CSRF limitations](/ja/4.2/ref/csrf/#csrf-limitations) requiring a site to
be deployed such that untrusted users don't have access to any subdomains,
[`django.contrib.sessions`](/ja/4.2/topics/http/sessions/#module-django.contrib.sessions) also has limitations. See [the session
topic guide section on security](/ja/4.2/topics/http/sessions/#topics-session-security) for details.

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

> **Note**
>
> 以下に説明する問題を回避するには [serving static files from a cloud service or CDN](/ja/4.2/howto/static-files/deployment/#staticfiles-from-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](https://httpd.apache.org/docs/2.4/mod/core.html#limitrequestbody) directive.
- If you are serving your own static files, be sure that handlers like Apache's
  `mod_php`, which would execute static files as code, are disabled. You don't
  want users to be able to execute arbitrary code by uploading and requesting a
  specially crafted file.
- Django's media upload handling poses some vulnerabilities when that media is
  served in ways that do not follow security best practices. Specifically, an
  HTML file can be uploaded as an image if that file contains a valid PNG
  header followed by malicious HTML. This file will pass verification of the
  library that Django uses for [`ImageField`](/ja/4.2/ref/models/fields/#django.db.models.ImageField) image
  processing (Pillow). When this file is subsequently displayed to a
  user, it may be displayed as HTML depending on the type and configuration of
  your web server.

  No bulletproof technical solution exists at the framework level to safely
  validate all user uploaded file content, however, there are some other steps
  you can take to mitigate these attacks:

  1. One class of attacks can be prevented by always serving user uploaded
     content from a distinct top-level or second-level domain. This prevents
     any exploit blocked by [same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) protections such as cross
     site scripting. For example, if your site runs on `example.com`, you
     would want to serve uploaded content (the [`MEDIA_URL`](/ja/4.2/ref/settings/#std-setting-MEDIA_URL) setting)
     from something like `usercontent-example.com`. It's *not* sufficient to
     serve content from a subdomain like `usercontent.example.com`.
  2. Beyond this, applications may choose to define a list of allowable
     file extensions for user uploaded files and configure the web server
     to only serve such files.

## Additional security topics

While Django provides good security protection out of the box, it is still
important to properly deploy your application and take advantage of the
security protection of the web server, operating system and other components.

- Make sure that your Python code is outside of the web server's root. This
  will ensure that your Python code is not accidentally served as plain text
  (or accidentally executed).
- Take care with any [user uploaded files](/ja/4.2/ref/models/fields/#file-upload-security).
- Django does not throttle requests to authenticate users. To protect against
  brute-force attacks against the authentication system, you may consider
  deploying a Django plugin or web server module to throttle these requests.
- Keep your [`SECRET_KEY`](/ja/4.2/ref/settings/#std-setting-SECRET_KEY), and [`SECRET_KEY_FALLBACKS`](/ja/4.2/ref/settings/#std-setting-SECRET_KEY_FALLBACKS) if in
  use, secret.
- It is a good idea to limit the accessibility of your caching system and
  database using a firewall.
- Take a look at the Open Web Application Security Project (OWASP) [Top 10
  list](https://owasp.org/Top10/) which identifies some common vulnerabilities in web applications. While
  Django has tools to address some of the issues, other issues must be
  accounted for in the design of your project.
- Mozilla discusses various topics regarding [web security](https://infosec.mozilla.org/guidelines/web_security.html). Their
  pages also include security principles that apply to any system.