Qu’est-ce que le CSRF ?
Le CSRF, pour cross-site request forgery, est une attaque qui fait exécuter à un utilisateur connecté une action qu’il n’a pas voulue sur un site où il est authentifié. On le traduit par falsification de requête inter-site ; on rencontre aussi les abréviations XSRF et l’expression session riding.
Le mécanisme exploite un comportement normal du navigateur : celui-ci joint automatiquement les cookies du site cible à toute requête qui lui est adressée, y compris quand la requête part d’une page hébergée ailleurs. Le serveur voit une requête authentifiée et l’exécute.
Seules les actions qui modifient un état sont concernées : virement, changement d’adresse e-mail, suppression d’un enregistrement, attribution de droits. Une attaque CSRF ne permet pas de lire la réponse renvoyée par le serveur, seulement de déclencher l’action.
Comment fonctionne une attaque CSRF ?
Le scénario type tient en quatre temps.
- La victime est connectée à une application, par exemple un back-office ou une banque en ligne. Son cookie de session est valide.
- Dans le même navigateur, elle ouvre une page contrôlée par l’attaquant, atteinte par un lien reçu par e-mail, un forum ou une publicité.
- Cette page contient une requête vers l’application cible : une balise image pointant vers une URL d’action, ou un formulaire envoyé automatiquement en JavaScript.
- Le navigateur envoie la requête avec le cookie de session. L’application, qui ne vérifie que l’authentification, exécute l’action.
L’attaquant n’a besoin ni du mot de passe, ni d’accéder à la machine. Il lui suffit de connaître le format de la requête, ce qui est trivial quand l’application est publique ou que sa documentation d’API l’est.
CSRF ou XSS : quelle différence ?
Le XSS injecte du code dans une page pour le faire exécuter par le navigateur d’autres utilisateurs. Le CSRF n’injecte rien : il fabrique une requête légitime en apparence depuis un autre domaine.
La formule qui aide à retenir : le XSS exploite la confiance de l’utilisateur envers le site, le CSRF exploite la confiance du site envers l’utilisateur.
Conséquence pratique : une faille XSS annule les protections anti-CSRF. Le code injecté s’exécute dans le contexte du site et peut lire le jeton anti-CSRF avant de l’utiliser. Traiter le CSRF sans traiter le XSS ne sert donc à rien.
Comment se protéger du CSRF ?
Les défenses se combinent, aucune ne suffit seule.
- Jeton anti-CSRF (synchronizer token) : le serveur place une valeur imprévisible dans le formulaire et la vérifie à la réception. C’est la protection de référence, intégrée d’origine dans Django, Rails, Laravel, Spring Security et ASP.NET Core.
- Attribut SameSite sur les cookies : en Lax ou Strict, le navigateur cesse d’envoyer le cookie sur les requêtes venues d’un autre site. Chrome applique Lax par défaut depuis 2020, ce qui a fortement réduit la surface d’attaque sans l’annuler.
- Vérification des en-têtes Origin et Referer côté serveur pour les requêtes sensibles.
- Respect de la sémantique HTTP : aucune action modifiant un état ne doit passer par une requête GET.
- Ré-authentification ou confirmation par un second facteur sur les opérations critiques : changement de mot de passe, virement, ajout d’un administrateur.
Le réflexe le plus rentable reste de s’appuyer sur la protection native du framework plutôt que d’écrire la sienne, puis de vérifier qu’elle n’a pas été désactivée sur certaines routes lors d’un branchement d’API. C’est là que se trouvent la plupart des failles CSRF encore exploitables.
Le CSRF est-il toujours dans l’OWASP Top 10 ?
Plus en tant que catégorie autonome. Le CSRF figurait au Top 10 de 2013, en est sorti dans l’édition 2017 parce que les frameworks intégraient la protection par défaut, et il est depuis rattaché à la catégorie Broken Access Control, en tête du classement dans les éditions 2021 comme 2025. La faiblesse correspondante, référencée CWE-352, est explicitement listée dans la catégorie A01:2025.
Sortir du classement comme ligne distincte n’est pas disparaître du terrain. Les cas rencontrés en test d’intrusion concernent surtout des API internes, des back-offices anciens et des routes où la vérification a été désactivée pour débloquer une intégration, puis jamais réactivée.
Exemples ou cas d’usage concrets
Une administratrice reste connectée au back-office de son site e-commerce dans un onglet. Dans un autre, elle ouvre un lien reçu par message. La page envoie en arrière-plan un formulaire vers l’URL de création de compte administrateur du back-office, et le compte est créé sans qu’aucun écran ne s’affiche.
Un salarié consulte son espace RH pour poser des congés, puis visite un forum. Une image intégrée dans un message pointe vers une URL de l’application RH qui modifie un coordonnée bancaire. La requête part en GET, ce qui suffit parce que l’application accepte de modifier un état sur une simple lecture.
Une API interne a vu sa protection anti-CSRF désactivée pour faire fonctionner un connecteur avec un outil tiers. Six mois plus tard, l’ensemble des routes de cette API est exploitable depuis n’importe quel site que visite un utilisateur connecté.
Le point commun de ces cas : rien n’apparaît côté victime. Aucune alerte, aucun écran, aucune trace visible. La détection se fait a posteriori, dans les journaux du serveur, à condition qu’ils enregistrent l’en-tête Referer et l’origine des requêtes.
Qui traite le CSRF dans une équipe ?
La correction relève des développeurs back-end, qui appliquent la protection du framework et la maintiennent sur les nouvelles routes. La détection relève de trois autres profils.
- Pentester applicatif : identifie les endpoints non protégés lors d’un test d’intrusion web.
- Ingénieur AppSec ou DevSecOps : branche les analyses SAST et DAST dans la chaîne d’intégration et suit les corrections.
- Architecte sécurité : fixe les règles de gestion de session et de cookies applicables à l’ensemble du système d’information.
Sur un poste de développeur back-end, savoir expliquer la différence entre CSRF et XSS et citer deux protections concrètes reste une question d’entretien courante. Elle sert moins à vérifier des connaissances qu’à repérer les candidats qui n’ont jamais regardé ce que fait leur framework par défaut.