Intergiciels (« middleware »)

Ce document présente tous les composants intergiciels livrés avec Django. Pour plus d’informations sur la façon de les utiliser et sur la manière d’écrire ses propres intergiciels, consultez le guide d’utilisation des intergiciels.

Intergiciels disponibles

Intergiciel de cache

class UpdateCacheMiddleware[source]
class FetchFromCacheMiddleware[source]

Active le cache global du site. Quand il est actif, chaque page générée par Django est mise en cache pour une durée équivalente au réglage CACHE_MIDDLEWARE_SECONDS. Voir la documentation du cache.

Intergiciel « common »

class CommonMiddleware[source]

Ajoute quelques commodités pour les perfectionnistes :

  • Interdit l’accès aux agents utilisateurs (navigateurs) mentionnés dans le réglage DISALLOWED_USER_AGENTS, qui devrait contenir une liste d’objets expression régulière compilés.

  • Effectue une réécriture d’URL sur la base des réglages APPEND_SLASH et PREPEND_WWW.

    Si APPEND_SLASH vaut True et que l’URL initiale ne se termine pas par une barre oblique et que l’URL n’est pas trouvée dans les configuration d’URL, une nouvelle URL est formée en y ajoutant une barre oblique à la fin. Si la nouvelle URL est trouvée dans la configuration d’URL, Django redirige la requête vers cette URL. Sinon, l’URL de départ est traitée comme d’habitude.

    Par exemple, foo.com/bar sera redirigée vers foo.com/bar/ s’il n’existe pas de motif d’URL valide correspondant à foo.com/bar mais qu’il existe un motif valide pour foo.com/bar/.

    Si PREPEND_WWW vaut True, les URL ne commençant pas par « www. » seront redirigées vers la même URL commençant par « www. ».

    Ces deux options visent à normaliser les URL. L’idée étant que chaque URL devrait exister sous une et une seule forme. Techniquement, une URL foo.com/bar est différente de foo.com/bar/ – un index de moteur de recherche les traiterait comme des URL distinctes – ce qui justifie la bonne pratique de normaliser les URL.

  • Définit l’en-tête Content-Length pour les réponses qui ne sont pas de type flux.

CommonMiddleware.response_redirect_class

La valeur par défaut est HttpResponsePermanentRedirect. Créez une sous-classe de CommonMiddleware et surchargez cet attribut pour personnaliser les redirections émises par l’intergiciel.

class BrokenLinkEmailsMiddleware[source]

Intergiciel GZip

class GZipMiddleware[source]

Avertissement

Les chercheurs en sécurité ont récemment découvert que lorsque des techniques de compression (y compris avec GZipMiddleware) sont utilisés sur un site Web, le site peut être exposé à un certain nombre d’attaques potentielles. Avant d’utiliser GZipMiddleware pour votre site, vous devriez évaluer avec soin si vous êtes une cible possible de ces attaques. Si vous doutez d’une façon ou d’une autre à ce sujet, vous devriez éviter d’utiliser cet intergiciel. Pour plus de détails, consultez le document présentant la faille (PDF) et breachattack.com.

L’intergiciel django.middleware.gzip.GZipMiddleware compresse le contenu pour les navigateurs qui prennent en charge la compression GZip (tous les navigateurs modernes).

Cet intergiciel devrait être placé avant tout autre intergiciel qui a besoin de lire ou d’écrire le corps de la réponse afin que la compression puisse avoir lieu après.

Il ne compresse PAS le contenu si l’un des critères suivants est vrai :

  • La taille du corps du contenu est plus petite que 200 octets.
  • La réponse a déjà défini l’en-tête Content-Encoding.
  • La requête (le navigateur) n’a pas envoyé d’en-tête Accept-Encoding incluant gzip.

Si la réponse possède un en-tête ETag, l’ETag est rendu faible pour se conformer à RFC 7232#section-2.1.

Vous pouvez appliquer la compression GZip pour des vues individuelles en utilisant le décorateur gzip_page().

Intergiciel GET conditionnel

class ConditionalGetMiddleware[source]

Traite les opérations GET conditionnelles. Si la réponse ne possède pas d’en-tête ETag, l’intergiciel en crée un si nécessaire. Si la réponse possède un en-tête ETag ou Last-Modified et que la requête possède l’en-tête If-None-Match ou If-Modified-Since, la réponse est remplacée par HttpResponseNotModified.

Intergiciel de locale

class LocaleMiddleware[source]

Active le choix de la langue en fonction de données de la requête. Le contenu est alors personnalisé par utilisateur. Voir la documentation sur l’internationalisation.

LocaleMiddleware.response_redirect_class

La valeur par défaut est HttpResponseRedirect. Créez une sous-classe de LocaleMiddleware et surchargez cet attribut pour personnaliser les redirections émises par l’intergiciel.

Intergiciel de messages

class MessageMiddleware[source]

Active la prise en charge des messages par session ou par cookie. Voir la documentation sur les messages.

Intergiciel de sécurité

Avertissement

Si votre situation de déploiement le permet, il est généralement préférable de déléguer au serveur Web frontal la fonctionnalité fournie par l’intergiciel SecurityMiddleware. De cette façon, si certaines requêtes ne sont pas fournies par Django (comme des fichiers statiques ou des fichiers envoyés par les utilisateurs), elles bénéficieront de la même protection que les requêtes servies par l’application Django.

class SecurityMiddleware[source]

L’intergiciel django.middleware.security.SecurityMiddleware fournit plusieurs améliorations de sécurité au cycle de requête/réponse. Chaque amélioration peut être activée ou désactivée indépendamment par un réglage.

Sécurité de transport HTTP stricte (HSTS)

Pour les sites qui ne devraient pouvoir être accédés que par HTTPS, vous pouvez demander aux navigateurs modernes de refuser les connexions à votre nom de domaine si la connexion n’est pas sécurisée (pour une certaine période de temps) en définissant l”en-tête « Strict-Transport-Security ». Cela réduit l’exposition à certaines attaques de type « homme du milieu » (MITM) par détournement SSL.

SecurityMiddleware définit cet en-tête pour vous sur toutes les réponses HTTPS si vous définissez le réglage SECURE_HSTS_SECONDS à une valeur entière différente de zéro.

Lors de l’activation de HSTS, il est recommandé d’utiliser d’abord une faible valeur pour tester, par exemple SECURE_HSTS_SECONDS = 3600 pour une heure. Chaque fois qu’un navigateur Web lit l’en-tête HSTS pour votre site, il refusera de communiquer de manière non sécurisée (par HTTP) avec votre domaine pour la durée de temps indiquée. Après avoir obtenu confirmation que toutes les ressources de votre site sont servies de manière sécurisée (c’est-à-dire que HSTS ne casse rien du tout), il est alors possible et souhaité d’augmenter cette valeur afin que les visiteurs occasionnels soient protégés (il est fréquent de voir 31536000 secondes, c’est-à-dire 1 an).

De plus, si vous définissez le réglage SECURE_HSTS_INCLUDE_SUBDOMAINS à True, SecurityMiddleware ajoute la directive includeSubDomains à l’en-tête Strict-Transport-Security. C’est recommandé (pour autant que tous les sous-domaines soient servis exclusivement par HTTPS), sinon votre site pourrait rester vulnérable au travers d’une connexion non sécurisée à un sous-domaine.

Si vous souhaitez soumettre votre site à la liste de préchargement du navigateur, définissez le réglage SECURE_HSTS_PRELOAD à True. Cela ajoute la directive preload à l’en-tête Strict-Transport-Security.

Avertissement

La politique HSTS s’applique à un domaine entier, pas seulement pour l’URL de la réponse pour laquelle vous définissez cet en-tête. Il ne faut donc l’utiliser que si tout le domaine est servi exclusivement par HTTPS.

Les navigateurs respectant scrupuleusement l’en-tête HSTS refuseront aux utilisateurs de passer outre les avertissements et de se connecter à un site avec un certificat SSL expiré, auto-signé ou non valide pour toute autre raison. Si vous utilisez HSTS, assurez-vous que vos certificats sont en bon état et qu’ils le restent !

Note

Si votre déploiement se trouve derrière un répartiteur de charge ou un serveur mandataire inverse, et que l’en-tête Strict-Transport-Security n’est pas ajouté à vos réponses, il est possible que Django ne détecte pas qu’il fonctionne sur une connexion sécurisée ; il faut alors définir le réglage SECURE_PROXY_SSL_HEADER.

X-Content-Type-Options: nosniff

Certains navigateurs essaient de deviner les types de contenu des ressources qu’ils appellent, sans tenir compte de l’en-tête Content-Type. Bien que cela puisse aider à afficher des sites dont les serveurs sont mal configurés, cela peut aussi poser un risque de sécurité.

Si votre site sert des fichiers que des utilisateurs ont envoyés, un utilisateur mal intentionné pourrait envoyer un fichier spécialement écrit pour qu’il soit interprété comme du HTML ou du JavaScript par le navigateur alors que vous vous attendiez à ce que son contenu soit inoffensif.

Pour empêcher le navigateur de deviner le type de contenu et le forcer à toujours utiliser le type indiqué dans l’en-tête Content-Type, vous pouvez définir l’en-tête X-Content-Type-Options: nosniff. SecurityMiddleware s’en charge pour toutes les réponses si le réglage SECURE_CONTENT_TYPE_NOSNIFF est défini à True.

Notez que dans la plupart des situations de déploiement où Django n’est pas impliqué dans le service de fichiers envoyés par les utilisateurs, ce réglage ne va pas aider. Par exemple, si le contenu de MEDIA_URL est directement servi par le serveur Web frontal (nginx, Apache, etc.), c’est par ce dernier que l’en-tête doit être défini. D’un autre côté, si vous utilisez Django pour s’occuper de choses comme exiger une autorisation avant de pouvoir télécharger des fichiers et que vous n’êtes pas en mesure de faire définir cet en-tête par le serveur Web, ce réglage sera utile.

X-XSS-Protection: 1; mode=block

Certains navigateurs ont la capacité de bloquer du contenu qui ressemble à une attaque XSS. Ils le font en examinant le contenu JavaScript dans les paramètres GET ou POST des pages. Si le JavaScript est rejoué dans la réponse du serveur, l’affichage de la page est bloqué et une page d’erreur s’affiche à la place.

L”en-tête X-XSS-Protection est utilisé pour contrôler l’opération du filtre XSS.

Pour activer le filtre XSS dans le navigateur et le forcer à toujours bloquer les suspicions d’attaque XSS, vous pouvez définir l’en-tête X-XSS-Protection: 1; mode=block. SecurityMiddleware s’en charge pour toutes les réponses si le réglage SECURE_BROWSER_XSS_FILTER est défini à True.

Avertissement

Le filtre XSS du navigateur est une mesure de défense utile, mais on ne peut pas s’y fier de manière exclusive. Il ne peut pas détecter toutes les attaques XSS et ce n’est pas pris en charge avec tous les navigateurs. Prenez soin de toujours valider et nettoyer toutes les valeurs entrées pour éviter les attaques XSS.

Redirection SSL

Si votre site offre à la fois des connexions HTTP et HTTPS, la plupart des utilisateurs obtiendront une connexion non sécurisée par défaut. Pour une meilleure sécurité, vous devriez rediriger toutes les connexions HTTP vers HTTPS.

Si vous définissez le réglage SECURE_SSL_REDIRECT à True, SecurityMiddleware va rediriger de manière permanente (HTTP 301) toutes les connexions HTTP vers HTTPS.

Note

Pour des raisons de performance, il est préférable de procéder à ces redirections en dehors de Django, dans une répartiteur de charge frontal ou un serveur mandataire inverse tel que nginx. SECURE_SSL_REDIRECT est prévu pour des situations de déploiement où ce scénario n’est pas envisageable.

Si le réglage SECURE_SSL_HOST possède une valeur, toutes les redirections seront envoyées vers cet hôte au lieu de l’hôte d’origine de la requête.

Si certaines pages de votre site doivent rester disponibles par HTTP sans être redirigées vers HTTPS, vous pouvez ajouter des expressions régulières correspondantes à ces URL dans le réglage SECURE_REDIRECT_EXEMPT (sous forme de liste).

Note

Si votre déploiement se trouve derrière un répartiteur de charge ou un serveur mandataire inverse, et que Django ne semble pas pouvoir détecter si une requête est déjà sécurisée ou non, il peut alors être nécessaire de définir le réglage SECURE_PROXY_SSL_HEADER.

Intergiciel de session

class SessionMiddleware[source]

Active la prise en charge des sessions. Voir la documentation sur les sessions.

Intergiciel de site

class CurrentSiteMiddleware[source]

Ajoute l’attribut site représentant le site en cours à chaque objet HttpRequest entrant. Voir la documentation sur les sites.

Intergiciel d’authentification

class AuthenticationMiddleware

Ajoute l’attribut user représentant l’utilisateur actuellement connecté à chaque objet HttpRequest entrant. Voir Authentification dans les requêtes Web.

class RemoteUserMiddleware

Intergiciel permettant d’exploiter l’authentification fournie par le serveur Web. Voir Authentification avec REMOTE_USER pour les détails d’utilisation.

class PersistentRemoteUserMiddleware

Intergiciel permettant d’exploiter l’authentification fournie par le serveur Web lorsqu’elle n’est activée que sur la page de connexion. Voir Utilisation de REMOTE_USER uniquement pour les pages de connexion pour les détails d’utilisation.

Intergiciel de protection CSRF

class CsrfViewMiddleware[source]

Ajoute la protection contre les attaques Cross Site Request Forgeries en ajoutant des champs de formulaires masqués aux formulaires POST et en contrôlant que les requêtes contiennent la valeur correcte. Voir la documentation concernant la protection contre les attaques Cross Site Request Forgery.

Intergiciel X-Frame-Options

class XFrameOptionsMiddleware[source]

Protection simple contre les attaques par détournement de clic au moyen de l’en-tête X-Frame-Options.

Ordre des intergiciels

Voici quelques indications au sujet de l’ordre des diverses classes d’intergiciel Django :

  1. SecurityMiddleware

    Il devrait se trouver assez haut dans la liste si vous prévoyez d’activer la redirection SSL car cela évite de passer par plusieurs autres intergiciels inutiles.

  2. UpdateCacheMiddleware

    Avant ceux qui modifient l’en-tête Vary (SessionMiddleware, GZipMiddleware, LocaleMiddleware).

  3. GZipMiddleware

    Avant tout intergiciel susceptible de modifier ou d’utiliser le corps de la réponse.

    Après UpdateCacheMiddleware: modifie l’en-tête Vary.

  4. SessionMiddleware

    Avant tout intergiciel pouvant générer une exception déclenchant une vue d’erreur (comme par exemple PermissionDenied) dans le cas où vous utilisez CSRF_USE_SESSIONS.

    Après UpdateCacheMiddleware: modifie l’en-tête Vary.

  5. ConditionalGetMiddleware

    Avant tout intergiciel pouvant modifier la réponse (définit l’en-tête ETag).

    Après GZipMiddleware afin qu’il ne calcule pas d’en-tête ETag pour du contenu compressé gzip.

  6. LocaleMiddleware

    Doit être dans les premiers, après SessionMiddleware (utilise les données de sessions) et UpdateCacheMiddleware (modifie l’en-tête Vary).

  7. CommonMiddleware

    Avant tout intergiciel qui pourrait modifier la réponse (il définit l’en-tête Content-Length). Un intergiciel apparaissant avant CommonMiddleware et modifiant la réponse doit réinitialiser Content-Length.

    Dans les tout premiers : il redirige lorsque APPEND_SLASH ou PREPEND_WWW valent True.

    Après SessionMiddleware si vous utilisez CSRF_USE_SESSIONS.

  8. CsrfViewMiddleware

    Avant tout intergiciel comptant sur le fait que des attaques CSRF ont déjà été contrées.

    Avant RemoteUserMiddleware ou tout autre intergiciel d’authentification qui pourrait effectuer une connexion et ainsi activer la rotation du jeton CSRF, avant d’appeler la suite de la chaîne d’intergiciels.

    Après SessionMiddleware si vous utilisez CSRF_USE_SESSIONS.

  9. AuthenticationMiddleware

    Après SessionMiddleware: utilise le stockage des sessions.

  10. MessageMiddleware

    Après SessionMiddleware: peut utiliser le stockage basé sur les sessions.

  11. FetchFromCacheMiddleware

    Après tout intergiciel qui modifie l’en-tête Vary: cet en-tête est utilisé pour choisir une valeur pour la clé de hachage du cache.

  12. FlatpageFallbackMiddleware

    Devrait se situer dans les derniers car c’est un type d’intergiciel de dernier recours.

  13. RedirectFallbackMiddleware

    Devrait se situer dans les derniers car c’est un type d’intergiciel de dernier recours.

Back to Top