Django fournit des protections intégrées robustes contre les vulnérabilités web courantes (le OWASP Top 10) — la sécurité est une priorité centrale de la conception, et de nombreuses protections sont activées par défaut. Les comprendre est essentiel pour construire des applications sécurisées et ne pas désactiver accidentellement ces garde-fous.
1. Injection SQL — prévenue par l'ORM
# ✅ the ORM uses PARAMETERIZED queries automatically — safe by default
User.objects.filter(username=user_input) # input is never executable SQL
# ⚠️ raw SQL CAN be vulnerable — always parameterize:
User.objects.raw("SELECT * FROM users WHERE name = %s", [user_input]) # ✅ parameterized
# NEVER: f"SELECT ... WHERE name = '{user_input}'" ❌ injectable
L'ORM paramétrize toutes les requêtes, prévenant l'injection SQL par défaut — une classe majeure de vulnérabilité éliminée à moins que vous n'écriviez du SQL brut non sécurisé.
2. XSS (Cross-Site Scripting) — auto-échappement du template
{{ user_input }} <!-- AUTO-ESCAPED: <script> → <script> → safe -->
{{ trusted|safe }} <!-- opt out ONLY for content you fully trust -->
Les templates Django auto-échappent la sortie des variables par défaut, neutralisant le HTML/scripts injectés — protection XSS intégrée.
3. CSRF (Cross-Site Request Forgery) — protection par token
<form method="post">
{% csrf_token %} <!-- REQUIRED — Django validates this token on POST -->
...
</form>
Le middleware CSRF requiert un token sur les requêtes changeant d'état (POST/PUT/DELETE), bloquant les requêtes forgées d'autres sites.
4. Clickjacking — X-Frame-Options
# XFrameOptionsMiddleware (default) sends X-Frame-Options: DENY
# → prevents your site from being embedded in a malicious <iframe>
5. Gestion sécurisée des mots de passe
# passwords are HASHED with strong algorithms (PBKDF2 by default), never plaintext
user.set_password(raw_password) # hashes automatically
# + password validators enforce strength (length, common-password checks)
6. HTTPS / sécurité du transport (paramètres de production)
# settings.py — enable these in production
SECURE_SSL_REDIRECT = True # force HTTPS
SESSION_COOKIE_SECURE = True # cookies only over HTTPS
CSRF_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000 # HSTS — enforce HTTPS
SECURE_CONTENT_TYPE_NOSNIFF = True
La responsabilité critique : ne pas affaiblir les défauts
⚠️ DEBUG = False in production — DEBUG=True leaks tracebacks, settings, source paths
⚠️ Keep SECRET_KEY secret (env vars, not code) — it signs sessions/tokens
⚠️ Set ALLOWED_HOSTS to prevent Host-header attacks
⚠️ Don't use |safe or mark_safe on untrusted input (reopens XSS)
⚠️ Always validate/sanitize input; use Django forms/serializers
⚠️ Run `python manage.py check --deploy` to audit production security settings
Pourquoi c'est important
La sécurité est critique pour toute application web, et comprendre les protections intégrées de Django est essentiel à la fois pour les exploiter et pour ne pas les affaiblir accidentellement — les défauts de sécurité solides de Django sont une raison majeure pour laquelle il est approuvé pour les applications sérieuses, mais ils ne vous protègent que si vous les comprenez et les respectez.
Django aborde les vulnérabilités web les plus courantes et dangereuses par défaut : l'ORM prévient l'injection SQL via les requêtes paramétrées, l'auto-échappement du template prévient le XSS, le middleware CSRF prévient la demande forgée intersite, la protection contre le clickjacking est intégrée, et les mots de passe sont hachés de manière sécurisée — éliminant des catégories entières de vulnérabilités que les développeurs doivent gérer manuellement (et se trompent souvent) dans les frameworks moins axés sur la sécurité.
Comprendre ces protections est important pour savoir qu'elles existent, les configurer correctement (en particulier les paramètres de sécurité de production pour HTTPS, les cookies sécurisés et HSTS), et — de manière critique — ne pas les désactiver accidentellement : les défaillances de sécurité Django les plus courantes proviennent de l'affaiblissement des défauts, comme laisser DEBUG=True en production (fuite de tracebacks sensibles et de paramètres aux attaquants), committer la SECRET_KEY, utiliser |safe/mark_safe sur une entrée non approuvée (réouvrant XSS), écrire du SQL brut non paramétrée (réouvrant l'injection), ou mal configurer ALLOWED_HOSTS.
Connaître les protections que Django fournit, comment configurer les paramètres de production sécurisés, et la responsabilité de ne pas affaiblir les défauts (plus l'utilisation de check --deploy pour auditer) est fondamental pour construire des applications sécurisées.
Parce que les applications web sont des cibles constantes d'attaque et que les défaillances de sécurité peuvent être catastrophiques (violations de données, compromission de compte), comprendre le modèle de sécurité de Django — à la fois ce qu'il protège automatiquement et votre responsabilité de maintenir ces protections — est une connaissance essentielle, à enjeux élevés qui reflète un développement professionnel et conscient de la sécurité, et est un sujet fréquent et important pour toute application de production.