CSRF (Cross-Site Request Forgery) : Qu'est-ce que c'est ?

Qu'est-ce que le CSRF (Cross-Site Request Forgery) ?

Le Cross-Site Request Forgery, abrégé CSRF (parfois aussi appelé XSRF ou « sea-surf »), est une attaque web qui exploite la confiance qu'un site accorde au navigateur de l'utilisateur. Concrètement, un attaquant crée une page malveillante contenant un formulaire ou un lien qui soumet automatiquement une requête vers un site sur lequel la victime est authentifiée. Comme le navigateur envoie automatiquement les cookies de session avec chaque requête, le site cible ne peut pas distinguer une requête légitime d'une requête forgée.

Imaginons un utilisateur connecté à son application bancaire en ligne. Sans protection CSRF, un attaquant pourrait intégrer dans un e-mail ou un site web un formulaire invisible qui soumet un ordre de virement vers son propre compte. Le navigateur de la victime exécuterait cette requête avec les cookies de session valides, et la banque traiterait l'opération comme légitime. Le CSRF est classé parmi les risques majeurs par l'OWASP (Open Web Application Security Project) et figure régulièrement dans le Top 10 des vulnérabilités web les plus critiques.

Cette attaque est particulièrement insidieuse car elle ne nécessite aucun vol de mot de passe ni d'injection de code dans l'application cible. Elle exploite uniquement le mécanisme d'authentification par cookies, qui reste le standard pour la plupart des applications web. Dans le contexte du RGPD applicable en Belgique et en Europe, une faille CSRF peut entraîner des fuites de données personnelles et exposer l'entreprise à des sanctions significatives.

Pourquoi le CSRF est important

La protection contre le CSRF est un pilier fondamental de la sécurité des applications web modernes. Son importance se manifeste dans plusieurs dimensions critiques pour les entreprises.

• Intégrité des actions utilisateur : sans protection CSRF, n'importe quelle action qu'un utilisateur peut effectuer (modifier un profil, passer une commande, supprimer des données) peut être déclenchée à son insu par un attaquant.
• Conformité RGPD : le règlement européen impose des mesures techniques appropriées pour protéger les données personnelles. Une application vulnérable au CSRF ne respecte pas cette obligation, exposant l'entreprise à des amendes pouvant atteindre 4% du chiffre d'affaires annuel.
• Confiance des utilisateurs : une faille exploitée détruit la confiance des utilisateurs envers la plateforme. Dans un contexte B2B, cela peut compromettre des relations commerciales durables.
• Classement OWASP Top 10 : le CSRF fait partie des vulnérabilités les plus couramment exploitées selon l'OWASP, ce qui en fait une cible privilégiée pour les attaquants automatisés et les scripts de scan.
• Protection native dans Django : le framework Django, utilisé par Kern-IT, intègre une protection CSRF activée par défaut via le middleware CsrfViewMiddleware, réduisant considérablement le risque pour les applications développées avec cette stack.

Comment ça fonctionne

Le mécanisme d'attaque CSRF repose sur le comportement automatique des navigateurs web qui attachent les cookies d'authentification à chaque requête vers un domaine donné. L'attaquant crée une page piégée contenant un formulaire HTML dont l'attribut action pointe vers l'URL cible, par exemple <form action="https://app-cible.be/transfert" method="POST">. Les champs cachés du formulaire pré-remplissent les paramètres de la requête malveillante, et un script JavaScript soumet automatiquement ce formulaire dès le chargement de la page.

La protection la plus répandue contre le CSRF est le token synchronisé (Synchronizer Token Pattern). Le serveur génère un token aléatoire unique pour chaque session utilisateur et l'intègre dans chaque formulaire HTML sous forme de champ caché. Lors de la soumission, le serveur vérifie que le token reçu correspond à celui stocké en session. Un attaquant ne peut pas deviner ce token car il ne peut pas lire le contenu des pages du domaine cible (Same-Origin Policy).

Django implémente cette protection via le middleware CsrfViewMiddleware et le template tag {% csrf_token %}. Chaque formulaire POST dans un template Django doit inclure ce tag, qui génère un champ caché contenant le token CSRF. Pour les requêtes AJAX, Django utilise un cookie CSRF (csrftoken) que le JavaScript peut lire et renvoyer dans un en-tête HTTP (X-CSRFToken). Les protections complémentaires incluent l'attribut SameSite sur les cookies de session et la vérification de l'en-tête Origin ou Referer.

Exemple concret

Chez Kern-IT, toutes nos applications Django bénéficient de la protection CSRF activée par défaut. Dans un projet de plateforme métier pour un client du secteur immobilier (proptech), les utilisateurs gèrent des biens immobiliers et des transactions financières via une interface web. Chaque formulaire, qu'il s'agisse de la création d'un bien, de la validation d'une offre ou de la modification de coordonnées bancaires, est protégé par un token CSRF généré automatiquement par Django.

Pour les interactions JavaScript avec notre API REST, nous avons configuré la récupération automatique du token CSRF depuis le cookie et son injection dans les en-têtes de chaque requête AJAX via un intercepteur Axios. Cette approche transparente garantit la protection sans impacter l'expérience utilisateur ni complexifier le code frontend. Lors de l'audit de sécurité, les tests de pénétration ont confirmé l'impossibilité d'exploiter le CSRF grâce à cette couche de protection native Django.

Mise en oeuvre

1. Activer le middleware CSRF : vérifiez que django.middleware.csrf.CsrfViewMiddleware est présent dans la liste MIDDLEWARE de votre fichier settings.py. Il est activé par défaut dans toute installation Django.
2. Inclure le token dans les formulaires : ajoutez {% csrf_token %} dans chaque balise <form> qui utilise la méthode POST dans vos templates Django.
3. Configurer les requêtes AJAX : pour les appels JavaScript, récupérez le cookie csrftoken et envoyez-le dans l'en-tête X-CSRFToken. Django fournit une documentation détaillée pour jQuery, Fetch API et Axios.
4. Activer SameSite sur les cookies : configurez SESSION_COOKIE_SAMESITE = "Lax" et CSRF_COOKIE_SAMESITE = "Lax" dans vos settings pour une couche de protection supplémentaire.
5. Configurer CSRF_TRUSTED_ORIGINS : listez explicitement les origines autorisées dans CSRF_TRUSTED_ORIGINS pour les déploiements multi-domaines ou derrière un reverse proxy.
6. Tester avec des outils OWASP : utilisez OWASP ZAP ou Burp Suite pour vérifier que votre protection CSRF est effective sur toutes les routes sensibles de l'application.

Technologies et outils associés

• Django CsrfViewMiddleware : middleware natif de Django qui gère automatiquement la génération et la vérification des tokens CSRF.
• OWASP ZAP : outil open source de test de sécurité automatisé, capable de détecter les formulaires non protégés contre le CSRF.
• Burp Suite : plateforme de test de sécurité web professionnelle avec des modules dédiés à la détection des vulnérabilités CSRF.
• SameSite Cookies : attribut de cookie supporté par les navigateurs modernes qui limite l'envoi de cookies dans les requêtes cross-origin.
• Content Security Policy (CSP) : en-tête HTTP qui réduit la surface d'attaque en limitant les sources de contenu autorisées.
• Helmet.js / django-csp : bibliothèques pour configurer facilement les en-têtes de sécurité HTTP dans les applications Node.js et Django.

Conclusion

Le CSRF reste une menace réelle pour les applications web qui ne mettent pas en place les protections adéquates. La bonne nouvelle pour les développeurs Django est que le framework fournit une protection robuste et activée par défaut, à condition de suivre les bonnes pratiques : inclure le token CSRF dans chaque formulaire, configurer correctement les requêtes AJAX, et maintenir les cookies de session avec les attributs de sécurité appropriés. Chez Kern-IT, nous intégrons systématiquement ces protections dans nos applications web et nos plateformes métier, complétées par des audits de sécurité réguliers conformes aux recommandations OWASP et aux exigences du RGPD.