ミドルウェア

このドキュメントでは、Djangoに付属するすべてのミドルウェアコンポーネントについて説明します。それらの使用方法と独自のミドルウェアの作成方法については、ミドルウェア使用ガイドを参照してください。

利用可能なミドルウェア

キャッシュミドルウェア

class UpdateCacheMiddleware

class FetchFromCacheMiddleware

サイト全体のキャッシュを有効にします。これらが有効になっている場合、：setting： `CACHE_MIDDLEWARE_SECONDS` 設定で定義されている限り、Djangoを利用した各ページがキャッシュされます。キャッシュドキュメントを参照してください。

「一般的な」ミドルウェア

class CommonMiddleware

完璧主義者のためのいくつかの便利さを追加します：

：setting： `DISALLOWED_USER_AGENTS` 設定でユーザーエージェントへのアクセスを禁止します。これはコンパイルされた正規表現オブジェクトのリストである必要があります。
：setting： `APPEND_SLASH` および：setting：` PREPEND_WWW` の設定に基づいてURLの書き換えを実行します。

：setting： `APPEND_SLASH` がTrueで、最初のURLがスラッシュで終わっておらず、URLconfに見つからない場合は、次のURLを追加して新しいURLを作成します。最後にスラッシュします。この新しいURLがURLconfで見つかった場合、Djangoはリクエストをこの新しいURLにリダイレクトします。それ以外の場合、初期URLは通常どおり処理されます。

たとえば、foo.com/barの有効なURLパターンがないが、がの有効なパターンを持っている場合、foo.com/barはfoo.com/bar/にリダイレクトされます。 X148X] 。

：setting： `PREPEND_WWW` がTrueの場合、先頭に「www」がないURL。先頭に「www」が付いた同じURLにリダイレクトされます。

これらのオプションは両方とも、URLを正規化することを目的としています。哲学は、各URLが1つの場所にのみ存在する必要があるということです。技術的には、URL foo.com/barはfoo.com/bar/とは異なります。検索エンジンインデクサーはそれらを個別のURLとして扱うため、URLを正規化することをお勧めします。

必要に応じて、 no_append_slash（）デコレータを使用して、個々のビューをAPPEND_SLASHの動作から除外できます。
```
from django.views.decorators.common import no_append_slash

@no_append_slash
def sensitive_fbv(request, *args, **kwargs):
    """View to be excluded from APPEND_SLASH."""
    return HttpResponse()
```
バージョン3.2で変更： no_append_slash（）デコレータのサポートが追加されました。
非ストリーミング応答のContent-Lengthヘッダーを設定します。

CommonMiddleware.response_redirect_class

デフォルトは HttpResponsePermanentRedirect です。 CommonMiddlewareをサブクラス化し、属性をオーバーライドして、ミドルウェアによって発行されるリダイレクトをカスタマイズします。

class BrokenLinkEmailsMiddleware

リンク切れ通知メールを：setting： `MANAGERS` に送信します（エラー報告を参照）。

GZipミドルウェア

class GZipMiddleware

警告

セキュリティ研究者は最近、圧縮技術（GZipMiddlewareを含む）がWebサイトで使用されると、サイトが多くの攻撃の可能性にさらされる可能性があることを明らかにしました。サイトでGZipMiddlewareを使用する前に、これらの攻撃を受けているかどうかを慎重に検討する必要があります。影響を受けているかどうかについて任意のに疑問がある場合は、GZipMiddlewareの使用を避ける必要があります。詳細については、 BREACHペーパー（PDF）および breakattack.com を参照してください。

django.middleware.gzip.GZipMiddlewareは、GZip圧縮を理解するブラウザー（すべての最新ブラウザー）のコンテンツを圧縮します。

このミドルウェアは、応答本文の読み取りまたは書き込みが必要な他のミドルウェアの前に配置して、後で圧縮が行われるようにする必要があります。

次のいずれかに該当する場合、コンテンツは圧縮されません。

コンテンツ本体の長さは200バイト未満です。
応答はすでにContent-Encodingヘッダーを設定しています。
リクエスト（ブラウザ）は、gzipを含むAccept-Encodingヘッダーを送信していません。

応答にETagヘッダーがある場合、ETagは RFC 7232＃section-2.1 に準拠するように弱くなります。

gzip_page（）デコレータを使用して、個々のビューにGZip圧縮を適用できます。

条件付きGETミドルウェア

class ConditionalGetMiddleware

条件付きGET操作を処理します。応答にETagヘッダーがない場合、ミドルウェアは必要に応じてヘッダーを追加します。応答にETagまたはLast-Modifiedヘッダーがあり、要求にIf-None-MatchまたはIf-Modified-Sinceがある場合、応答は HttpResponseNotModified に置き換えられます。 ]。

ロケールミドルウェア

class LocaleMiddleware

リクエストからのデータに基づいて言語を選択できるようにします。ユーザーごとにコンテンツをカスタマイズします。国際化ドキュメントを参照してください。

LocaleMiddleware.response_redirect_class

デフォルトは HttpResponseRedirect です。 LocaleMiddlewareをサブクラス化し、属性をオーバーライドして、ミドルウェアによって発行されるリダイレクトをカスタマイズします。

メッセージミドルウェア

class MessageMiddleware

Cookieベースおよびセッションベースのメッセージサポートを有効にします。メッセージのドキュメントを参照してください。

セキュリティミドルウェア

警告

展開状況が許せば、通常、フロントエンドWebサーバーにSecurityMiddlewareによって提供される機能を実行させることをお勧めします。そうすれば、Djangoによって処理されないリクエスト（静的メディアやユーザーがアップロードしたファイルなど）がある場合、それらはDjangoアプリケーションへのリクエストと同じ保護を受けます。

class SecurityMiddleware

django.middleware.security.SecurityMiddlewareは、要求/応答サイクルにいくつかのセキュリティ強化を提供します。それぞれを個別に有効または無効にすることができます。

：setting： `SECURE_BROWSER_XSS_FILTER`
：setting： `SECURE_CONTENT_TYPE_NOSNIFF`
：setting： `SECURE_HSTS_INCLUDE_SUBDOMAINS`
：setting： `SECURE_HSTS_PRELOAD`
：setting： `SECURE_HSTS_SECONDS`
：setting： `SECURE_REDIRECT_EXEMPT`
：setting： `SECURE_REFERRER_POLICY`
：setting： `SECURE_SSL_HOST`
：setting： `SECURE_SSL_REDIRECT`

HTTP Strict TransportSecurity

HTTPS経由でのみアクセスする必要があるサイトの場合、「Strict-Transport-Security」ヘッダー[を設定することにより、安全でない接続を介したドメイン名への接続を（一定期間）拒否するように最新のブラウザーに指示できます。 X234X]。これにより、SSLストリッピング中間者（MITM）攻撃への露出が減少します。

SecurityMiddlewareはすべてのHTTPS応答でこのヘッダーを設定します。

HSTSを有効にするときは、最初に小さな値をテストに使用することをお勧めします。たとえば、：setting： `SECURE_HSTS_SECONDS = 3600 ` 1時間。 WebブラウザがサイトからHSTSヘッダーを認識するたびに、指定された期間、ドメインとの安全でない通信（HTTPを使用）を拒否します。すべてのアセットがサイトで安全に提供されていることを確認したら（つまり、 HSTSは何も壊しませんでした）、この値を増やして、まれな訪問者を保護することをお勧めします（31536000秒、つまり 1年が一般的です）。

さらに、：setting： `SECURE_HSTS_INCLUDE_SUBDOMAINS` 設定をTrueに設定すると、SecurityMiddlewareはincludeSubDomainsディレクティブをStrict-Transport-Securityに追加します]ヘッダー。これをお勧めします（すべてのサブドメインがHTTPSのみを使用して提供されていると仮定します）。そうしないと、サブドメインへの安全でない接続を介してサイトが脆弱になる可能性があります。

サイトをブラウザプリロードリストに送信する場合は、：setting： `SECURE_HSTS_PRELOAD` 設定をTrueに設定します。これにより、preloadディレクティブがStrict-Transport-Securityヘッダーに追加されます。

警告

HSTSポリシーは、ヘッダーを設定した応答のURLだけでなく、ドメイン全体に適用されます。したがって、ドメイン全体がHTTPS経由でのみ提供される場合にのみ使用する必要があります。

HSTSヘッダーを適切に尊重するブラウザは、ユーザーが警告をバイパスして、期限切れ、自己署名、またはその他の方法で無効なSSL証明書を使用してサイトに接続することを拒否します。 HSTSを使用する場合は、証明書の状態が良好であることを確認し、そのままにしてください。

ノート

ロードバランサーまたはリバースプロキシサーバーの背後にデプロイされていて、Strict-Transport-Securityヘッダーが応答に追加されていない場合は、Djangoが安全な接続上にあることを認識していないことが原因である可能性があります。：setting： `SECURE_PROXY_SSL_HEADER` 設定が必要になる場合があります。

リファラーポリシー

ブラウザは、ユーザーがどのようにしてそこに到達したかに関する情報をサイトに送信する方法として、リファラーヘッダーを使用します。ユーザーがリンクをクリックすると、ブラウザはリンクページの完全なURLをリファラーとして送信します。これは、サイトにリンクしているユーザーを特定するなどの目的には役立ちますが、ユーザーが別のサイトにアクセスしていることを1つのサイトに通知することで、プライバシーの問題を引き起こす可能性もあります。

一部のブラウザには、ユーザーがリンクをクリックしたときにHTTP Refererヘッダーを送信する必要があるかどうかに関するヒントを受け入れる機能があります。このヒントは、リファラーポリシーヘッダーを介して提供されます。このヘッダーは、ブラウザーに対して次の3つの動作のいずれかを示唆する可能性があります。

完全なURL：RefererヘッダーでURL全体を送信します。たとえば、ユーザーがhttps://example.com/page.htmlにアクセスしている場合、Refererヘッダーには"https://example.com/page.html%22が含まれます。
オリジンのみ：リファラーの「オリジン」のみを送信します。オリジンは、スキーム、ホスト、および（オプションで）ポート番号で構成されます。たとえば、ユーザーがhttps://example.com/page.htmlにアクセスしている場合、発信元はhttps://example.com/になります。
リファラーなし：Refererヘッダーをまったく送信しません。

このヘッダーがブラウザに注意するように指示できる条件には、次の2種類があります。

同一生成元とクロスオリジン：https://example.com/1.htmlからhttps://example.com/2.htmlへのリンクは同一生成元です。 https://example.com/page.htmlからhttps://not.example.com/page.htmlへのリンクはクロスオリジンです。
プロトコルのダウングレード：リンクを含むページがHTTPS経由で提供されているが、リンク先のページがHTTPS経由で提供されていない場合、ダウングレードが発生します。

警告

サイトがHTTPS経由で提供されている場合、 DjangoのCSRF保護システムではRefererヘッダーが存在する必要があるため、Refererヘッダーを完全に無効にするとCSRF保護が妨げられます。 CSRF保護を維持しながら、Refererヘッダーを無効にすることの利点のほとんどを得るには、同一生成元のリファラーのみを有効にすることを検討してください。

SecurityMiddlewareは、：setting： `SECURE_REFERRER_POLICY` 設定に基づいて、Referrer-Policyヘッダーを設定できます（スペルに注意：ブラウザーはRefererヘッダーを送信するときにユーザーがリンクをクリックしますが、そうするかどうかをブラウザーに指示するヘッダーのスペルはReferrer-Policy）です。この設定の有効な値は次のとおりです。

no-referrer: このサイトでクリックされたリンクのリファラーを送信しないようにブラウザーに指示します。
no-referrer-when-downgrade: プロトコルのダウングレードが発生しない場合にのみ、リファラーとして完全なURLを送信するようにブラウザーに指示します。
origin: 完全なURLではなく、オリジンのみをリファラーとして送信するようにブラウザーに指示します。
origin-when-cross-origin: 同じオリジンリンクのリファラーとして完全なURLを送信し、クロスオリジンリンクのオリジンのみを送信するようにブラウザーに指示します。
same-origin: 完全なURLを送信するようにブラウザに指示しますが、同じオリジンのリンクに対してのみです。クロスオリジンリンクのリファラーは送信されません。
strict-origin: 完全なURLではなくオリジンのみを送信し、プロトコルのダウングレードが発生したときにリファラーを送信しないようにブラウザーに指示します。
strict-origin-when-cross-origin: リンクが同一生成元であり、プロトコルのダウングレードが発生しない場合に、完全なURLを送信するようにブラウザに指示します。リンクがクロスオリジンであり、プロトコルのダウングレードが発生しない場合は、オリジンのみを送信します。プロトコルのダウングレードが発生した場合、リファラーはありません。
unsafe-url: 常に完全なURLをリファラーとして送信するようにブラウザーに指示します。

不明なポリシー値

ポリシー値がユーザーエージェントによって不明である場合、フォールバックを提供するために複数のポリシー値を指定することができます。理解された最後に指定された値が優先されます。これをサポートするために、反復可能またはコンマ区切りの文字列を：setting： `SECURE_REFERRER_POLICY` で使用できます。

X-Content-Type-Options: nosniff

一部のブラウザは、Content-Typeヘッダーを上書きして、フェッチするアセットのコンテンツタイプを推測しようとします。これは、サーバーが不適切に構成されたサイトを表示するのに役立ちますが、セキュリティリスクをもたらす可能性もあります。

サイトがユーザーがアップロードしたファイルを提供している場合、悪意のあるユーザーが特別に細工したファイルをアップロードする可能性があります。このファイルは、無害であると予想されたときに、ブラウザーによってHTMLまたはJavaScriptとして解釈されます。

ブラウザがコンテンツタイプを推測せず、常にContent-Typeヘッダーで提供されるタイプを使用するように強制するには、 X-Content-Type-Options：nosniff ヘッダーを渡すことができます。 SecurityMiddlewareは、：setting： `SECURE_CONTENT_TYPE_NOSNIFF` 設定がTrueの場合、すべての応答に対してこれを実行します。

Djangoがユーザーがアップロードしたファイルの提供に関与していないほとんどのデプロイメント状況では、この設定は役に立ちません。たとえば、：setting： `MEDIA_URL` がフロントエンドWebサーバー（nginx、Apacheなど）から直接提供される場合は、このヘッダーをそこに設定する必要があります。一方、Djangoを使用してファイルをダウンロードするために認証を要求するなどの操作を行っていて、Webサーバーを使用してヘッダーを設定できない場合は、この設定が役立ちます。

X-XSS-Protection: 1; mode=block

一部のブラウザには、 XSS攻撃のように見えるコンテンツをブロックする機能があります。これらは、ページのGETまたはPOSTパラメーターでJavaScriptコンテンツを探すことによって機能します。サーバーの応答でJavaScriptが再生されると、ページのレンダリングがブロックされ、代わりにエラーページが表示されます。

X-XSS-Protectionヘッダーは、XSSフィルターの動作を制御するために使用されます。

ブラウザでXSSフィルタを有効にし、疑わしいXSS攻撃を常にブロックするように強制するには、X-XSS-Protection: 1; mode=blockヘッダーを渡すことができます。 SecurityMiddlewareは、：setting： `SECURE_BROWSER_XSS_FILTER` 設定がTrueの場合、すべての応答に対してこれを実行します。

警告

ブラウザーのXSSフィルターは有用な防御手段ですが、排他的に依存してはなりません。すべてのXSS攻撃を検出できるわけではなく、すべてのブラウザがヘッダーをサポートしているわけではありません。 XSS攻撃を防ぐために、すべての入力を検証およびサニタイズしていることを確認してください。

SSLリダイレクト

サイトがHTTP接続とHTTPS接続の両方を提供している場合、ほとんどのユーザーはデフォルトでセキュリティで保護されていない接続になります。最高のセキュリティを得るには、すべてのHTTP接続をHTTPSにリダイレクトする必要があります。

：setting： `SECURE_SSL_REDIRECT` 設定をTrueに設定すると、SecurityMiddlewareはすべてのHTTP接続を永続的に（HTTP 301）HTTPSにリダイレクトします。

ノート

パフォーマンス上の理由から、これらのリダイレクトはDjangoの外部、フロントエンドロードバランサーまたは nginx などのリバースプロキシサーバーで実行することをお勧めします。：setting： `SECURE_SSL_REDIRECT` は、これがオプションではない展開状況を対象としています。

：setting： `SECURE_SSL_HOST` 設定に値がある場合、すべてのリダイレクトは、最初に要求されたホストではなく、そのホストに送信されます。

HTTP経由で利用可能で、HTTPSにリダイレクトされないページがサイトにいくつかある場合は、：setting： `SECURE_REDIRECT_EXEMPT` 設定でそれらのURLに一致する正規表現を一覧表示できます。

ノート

ロードバランサーまたはリバースプロキシサーバーの背後にデプロイされていて、Djangoがリクエストが実際にすでに安全であるかどうかわからない場合は、：setting： `SECURE_PROXY_SSL_HEADER` 設定を設定する必要があります。

セッションミドルウェア

class SessionMiddleware

セッションサポートを有効にします。セッションドキュメントを参照してください。

サイトミドルウェア

class CurrentSiteMiddleware

現在のサイトを表すsite属性をすべての着信HttpRequestオブジェクトに追加します。サイトのドキュメントを参照してください。

認証ミドルウェア

class AuthenticationMiddleware

現在ログインしているユーザーを表すuser属性を、すべての着信HttpRequestオブジェクトに追加します。 Webリクエストでの認証を参照してください。

class RemoteUserMiddleware

Webサーバーが提供する認証を利用するためのミドルウェア。使用方法の詳細については、 REMOTE_USER を使用した認証を参照してください。

class PersistentRemoteUserMiddleware

Webサーバーを利用するためのミドルウェアは、ログインページでのみ有効になっている場合に認証を提供します。使用方法の詳細については、ログインページでのみREMOTE_USERを使用するを参照してください。

CSRF保護ミドルウェア

class CsrfViewMiddleware

POSTフォームに非表示のフォームフィールドを追加し、リクエストの正しい値を確認することで、クロスサイトリクエストフォージェリに対する保護を追加します。クロスサイトリクエストフォージェリ保護のドキュメントを参照してください。

X-Frame-Optionsミドルウェア

class XFrameOptionsMiddleware

X-Frame-Optionsヘッダーによるシンプルなクリックジャッキング保護。