# Documentation Django 5.2.8

# La sécurité dans Django

Ce document est un aperçu des fonctionnalités de sécurité dans Django. Il contient des conseils sur la sécurisation des sites basés sur Django.

## Toujours nettoyer les contenus en provenance des utilisateurs

La règle d’or en matière de sécurité des applications web est de ne jamais faire confiance aux contenus contrôlés par les utilisateurs. C’est pourquoi toute donnée en provenance d’utilisateurs doit être nettoyée avant d’être utilisée dans l’application. Consultez la documentation sur les formulaires pour plus de détails sur la validation des saisies des utilisateurs dans Django.

## Protection contre le « Cross site scripting » (XSS)

Les attaques XSS permettent à un intrus d’injecter des scripts clients dans les navigateurs des utilisateurs. Le principe général est de stocker les scripts malveillants dans la base de données d’où ils seront repris et affichés pour d’autres utilisateurs, ou encore d’amener les utilisateurs à cliquer sur un lien qui va provoquer l’exécution du JavaScript de l’attaquant dans le navigateur des utilisateurs. Cependant, les attaques XSS peuvent provenir de n’importe quelle source de données non fiable, comme les cookies ou les services Web, à chaque fois que les données ne sont pas suffisamment nettoyées avant d’être incluses dans une page.

L’utilisation des gabarits Django vous protège de la majorité des attaques XSS. Cependant, il est important de comprendre les protections appliquées et leurs limites.

Les gabarits de Django échappent des caractères spécifiques qui sont particulièrement dangereux en HTML. Bien que cela protège les utilisateurs de la plupart des saisies malveillantes, cela ne constitue pas une protection absolue. Par exemple, cela ne protège pas contre ceci :

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

Si `var` contient `'class1 onmouseover=javascript:func()'`, cela peut amener à une exécution de JavaScript non autorisée, selon la manière dont le navigateur produit le HTML imparfait (l’ajout de guillemets autour de cette valeur d’attribut réglerait ce cas).

Il est aussi important d’être particulièrement prudent lors de l’utilisation de `is_safe` avec des balises de gabarit personnalisées, avec la balise de gabarit `safe`, avec `mark_safe` et quand l’échappement automatique est désactivé.

De plus, si vous utilisez le système des gabarits pour produire du contenu autre que du HTML, les caractères et les mots nécessitant l’échappement peuvent être totalement différents.

Vous devez aussi être très prudent lorsque vous stockez du code HTML dans la base de données, en particulier quand ce contenu est sélectionné et affiché.

## Protection contre le « Cross site request forgery » (CSRF)

Les attaques CSRF permettent à une personne malveillante d’exécuter des actions en utilisant les données d’authentification d’un autre utilisateur sans que ce dernier ne s’en rende compte.

Django offre une protection intégrée contre la plupart des types d’attaques CSRF, pour autant que vous l’ayez activée et que vous l’utilisiez de manière appropriée. Toutefois, comme pour toute technique de protection, elle est limitée. Par exemple, il est possible de désactiver le module CSRF de manière globale ou pour certaines vues. Vous ne devriez le faire que si vous savez ce que vous faites. Il existe d’autres limites si votre site contient des sous-domaines qui ne sont pas sous votre contrôle.

La protection CSRF fonctionne en contrôlant un jeton dans chaque requête POST. Cela garantit qu’un utilisateur malveillant ne peut « rejouer » un envoi de formulaire POST sur votre site Web tout en faisant soumettre ce formulaire de manière involontaire par un autre utilisateur connecté. L’utilisateur malveillant devrait connaître le jeton secret qui est spécifique à l’utilisateur (en utilisant un cookie).

Lorsqu’il est déployé avec HTTPS, `CsrfViewMiddleware` vérifie que l’en-tête « HTTP referer » contient une URL de même origine (y compris le sous-domaine et le port). Comme HTTPS offre une sécurité supplémentaire, il est impératif de s’assurer que les connexions utilisent HTTPS quand c’est possible en redirigeant les requêtes de connexion non sécurisées et en utilisant HSTS pour les navigateurs qui le prennent en charge.

Soyez très prudent lorsque vous adaptez des vues avec le décorateur `csrf_exempt` et ne le faites qu’en cas d’absolue nécessité.

## Protection contre l’injection SQL

L’injection SQL est un type d’attaque où un utilisateur malveillant est capable d’exécuter du code SQL arbitraire sur une base de données. Il peut en résulter des suppressions d’enregistrements ou des divulgations de données.

Les jeux de requête de Django sont prémunies contre les injections SQL car leurs requêtes sont construites à l’aide de la paramétrisation des requêtes. Le code SQL d’une requête est défini séparément de ses paramètres. Comme ceux-ci peuvent provenir de l’utilisateur et donc non sécurisés, leur échappement est assuré par le pilote de base de données sous-jacent.

Django permet aussi aux développeurs d’écrire des requêtes brutes ou d’exécuter du code SQL personnalisé. Ces possibilités devraient être exploitées de manière parcimonieuse et il faut toujours prendre la précaution d’échapper proprement tout paramètre pouvant être contrôlé par l’utilisateur. De plus, il faut être prudent en utilisant `extra()` et `RawSQL`.

## Protection contre le détournement de clic (« clickjacking »)

Le détournement de clic est un type d’attaque où un site malveillant intègre un autre site dans un cadre. Cette attaque peut amener un utilisateur à cliquer de manière non désirée pour effectuer des actions non volontaires sur le site ciblé.

Django intègre une protection contre le détournement de clic sous la forme de `l'intergiciel X-Frame-Options` qui, dans un navigateur qui le prend en charge, peut empêcher un site d’être affiché à l’intérieur d’un cadre. Il est possible de désactiver cette protection par vue ou de configurer la valeur exacte de l’en-tête envoyé.

Cet intergiciel est fortement recommandé pour tout site qui n’a pas besoin de voir ses pages affichées dans un cadre par des sites tiers ou qui n’en a besoin que pour une section limitée du site.

## SSL/HTTPS

Le déploiement de votre site en HTTPS est toujours mieux pour la sécurité. Sans cela, il est possible que des utilisateurs malveillants du réseau interceptent des données d’authentification ou toute autre information transférée entre le client et le serveur et, dans certains cas, pour des attaquants réseau actifs, que des données soient modifiées au passage, dans l’une ou l’autre direction.

Si vous souhaitez profiter de la protection ajoutée par HTTPS et l’activer sur votre serveur, il peut être nécessaire de procéder à quelques étapes supplémentaires :

- Si nécessaire, définissez `SECURE_PROXY_SSL_HEADER`, en prenant soin de bien comprendre les avertissements correspondants. Sinon, cela pourrait provoquer des vulnérabilités CSRF, et son application incorrecte peut aussi être dangereuse !

- Définissez `SECURE_SSL_REDIRECT` à `True`, pour que les requêtes HTTP soient redirigées vers HTTPS.

  Prenez bonne note des mises en garde de `SECURE_PROXY_SSL_HEADER`. Dans le cas d’un serveur mandataire inverse, il peut être plus simple ou plus sûr de configurer le serveur web principal pour qu’il fasse lui-même la redirection vers HTTPS.

- Utilisez des cookies « sécurisés ».

  Si un navigateur se connecte initialement en HTTP, ce qui est le comportement par défaut de la plupart des navigateurs, il est possible que des cookies existants soient divulgués. Pour cette raison, vous devriez définir les réglages `SESSION_COOKIE_SECURE` et `CSRF_COOKIE_SECURE` à `True`. Cela indique au navigateur qu’il ne doit envoyer les cookies que par des connexions HTTPS. Notez que cela signifie que les sessions ne fonctionneront pas en HTTP et que la protection CSRF empêchera l’acceptation de données POST par HTTP (ce qui ne pose pas de problème si vous redirigez tout le trafic HTTP vers HTTPS).

- Utilisez Sécurité de transport HTTP stricte (HSTS) (HSTS)

  HSTS est un en-tête HTTP informant le navigateur que toute connexion future à un site particulier devra toujours utiliser HTTPS. Combiné avec la redirection des requêtes HTTP vers HTTPS, cela garantit que les connexions profiteront toujours de la sécurité ajoutée par SSL à partir du moment où une connexion réussie a eu lieu. HSTS peut être configuré soit avec `SECURE_HSTS_SECONDS`, `SECURE_HSTS_INCLUDE_SUBDOMAINS` et `SECURE_HSTS_PRELOAD`, soit directement au niveau du serveur web.

## Validation de l’en-tête Host

Django utilise l’en-tête `Host` fourni par le client pour construire les URL dans certains cas. Même si ces valeurs sont vérifiées pour empêcher les attaques Cross Site Scripting, une valeur `Host` contrefaite peut être exploitée pour des attaques de type Cross-Site Request Forgery, d’empoisonnement de cache et d’empoisonnement de liens dans les courriels.

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.

Pour plus de détails, consultez la documentation complète de `ALLOWED_HOSTS`.

Avertissement

Des versions précédentes de ce document recommandaient de configurer le serveur Web pour s’assurer qu’il valide les en-têtes HTTP `Host` entrants. Même si c’est toujours recommandé, bien des configurations de serveurs Web bien connus paraissant valider l’en-tête `Host` ne le font pas toujours en réalité. Par exemple, même si Apache est configuré pour que votre site Django soit servi depuis un hôte virtuel autre que celui par défaut ayant défini `ServerName`, il est encore possible qu’une requête HTTP corresponde à cet hôte tout en fournissant un en-tête `Host` contrefait. C’est pourquoi Django demande dorénavant que `ALLOWED_HOSTS` soit défini explicitement plutôt que de se fier à la configuration du serveur Web.

En plus, Django exige que vous activiez explicitement la prise en charge de l’en-tête `X-Forwarded-Host` (via le réglage `USE_X_FORWARDED_HOST`) si votre configuration l’exige.

## Politique de référencement

Les navigateurs utilisent l’en-tête `Referer` comme moyen d’envoyer l’information de provenance de l’utilisateur à un site. En définissant une politique de référencement (Referrer Policy), vous pouvez aider à protéger la confidentialité de vos utilisateurs, en limitant les cas de figure où l’en-tête `Referer` est défini. Consultez la section sur la politique de référencement de l’intergiciel de sécurité pour plus de détails.

## Politique d’ouverture d’origine croisée

L’en-tête cross-origin opener policy (COOP, politique d’ouverture d’origine croisée) permet aux navigateurs d’isoler une fenêtre de premier niveau à partir d’autres documents en les plaçant dans une groupe de contexte différent afin qu’ils ne puissent pas interagir directement avec la fenêtre de premier niveau. Si un document protégé par COOP ouvre une fenêtre pop-up, la propriété `window.opener` de celle-ci sera `null`. COOP protège contre les attaques d’origine croisée. Lisez la section sur la politique d’ouverture d’origine croisée de la référence de l’intergiciel de sécurité pour plus de détails.

## Sécurité des sessions

Tout comme les limites de CSRF exigeant qu’un site soit déployé de manière à ce que des utilisateurs non fiables n’aient pas accès à d’éventuels sous-domaines, `django.contrib.sessions` présente également certaines limites. Consultez la section sur la sécurité du guide thématique des sessions pour plus de détails.

## Contenu envoyé par les utilisateurs

Note

Considérez le service des fichiers statiques par un service en nuage ou un CDN pour éviter certains de ces problèmes.

- Si votre site accepte les téléversements de fichiers, il est fortement conseillé de limiter ces téléversements dans la configuration de votre serveur web à une taille raisonnable afin d’empêcher les attaques par déni de service (DOS). Dans Apache, cela peut être facilement défini en utilisant la directive LimitRequestBody.

- Si vous servez vous-même les fichiers statiques, soyez sûr que les gestionnaires comme `mod_php` d’Apache qui pourraient exécuter des fichiers statiques comme du code sont désactivés. Il n’est manifestement pas souhaitable que des utilisateurs puissent exécuter du code arbitraire en téléversant puis en accédant à un fichier spécialement prévu à cet effet.

- La gestion des envois de fichiers par Django présente certaines vulnérabilités lorsque ces fichiers sont ensuite servis selon des pratiques non sécurisées. Plus particulièrement, un fichier HTML peut être téléversé comme image si le fichier contient un en-tête PNG valide suivi de code HTML malicieux. Ce fichier passera avec succès les vérifications effectuées par la bibliothèque de traitement d’image utilisée par Django (Pillow) pour les champs `ImageField`. Au moment où le fichier est ensuite affiché pour un utilisateur, il se peut qu’il soit affiché comme un fichier HTML en fonction du type et de la configuration du serveur Web.

  Il n’existe actuellement pas de solution technique à toute épreuve dans l’infrastructure Django pour valider de manière sûre tous les contenus de fichiers envoyés par les utilisateurs. Cependant, il existe un certain nombre de mesures à prendre pour diminuer les risques de telles attaques :

  1. Une catégorie d’attaques peut être évitée en servant toujours les contenus envoyés par les utilisateurs à partir d’un autre nom de domaine de premier ou de deuxième niveau. Cela évite les attaques bloquées par les protections same-origin policy telles que les scripts inter-sites. Par exemple, si votre site est servi par `example.com`, il serait imaginable de servir les contenus téléversés (cf. réglage `MEDIA_URL`) à partir d’un site nommé `contenuutilisateur-example.com`. Il n’est pas suffisant de servir le contenu à partir d’un sous-domaine tel que `contenuutilisateur.example.com`.

  2. En plus de cette mesure, les applications peuvent choisir de définir une liste des extensions de fichiers autorisées pour les fichiers téléversés par les utilisateurs et configurer le serveur Web pour qu’il n’accepte de servir que ces fichiers.

## 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.

## Thèmes de sécurité supplémentaires

Même si Django offre nativement de bonnes protections de sécurité, il est toujours important de déployer proprement les applications et de profiter des protections de sécurité du serveur web, du système d’exploitation et d’autres composants.

- Prenez soin de placer votre code Python en dehors de la racine du serveur web. Ceci pour garantir que le code Python ne puisse pas être accidentellement servi en texte pur (ou exécuté accidentellement).

- Prenez garde aux fichiers envoyés par les utilisateurs.

- Django ne limite pas les requêtes d’authentification des utilisateurs. Pour se protéger des attaques en force brute contre le système d’authentification, il faut envisager le déploiement d’un complément Django ou d’un module du serveur web pour limiter ces requêtes.

- Assurez-vous de conserver secret votre réglage `SECRET_KEY`, ainsi que `SECRET_KEY_FALLBACKS`, si vous l’utilisez.

- C’est une bonne pratique que de limiter l’accès au système de cache et à la base de données par un pare-feu.

- Jetez un œil à la liste Top 10 du projet Open Web Application Security (OWASP) qui identifie quelques vulnérabilités fréquentes dans les applications Web. Bien que Django possède des outils pour affronter certains de ces problèmes, d’autres doivent être pris en compte durant la conception de votre projet.

- Mozilla parle de différents sujets concernant la sécurité Web. Leurs pages contiennent également des principes de sécurité qui s’appliquent à tout système.