--- id: CP-053 slug: csrf-requete-forcee-inter-sites lang: fr title: "Le CSRF : l'action forcée à votre insu" description: Un site piégé ou un message peut faire agir votre navigateur à votre place sur un service où vous êtes connecté. Voici le mécanisme et les parades. canonical_url: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ markdown_url: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, « Le CSRF : l'action forcée à votre insu », Cyberpedia, 2026. https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ (CC BY 4.0)" wing: 1 theme: understand_hacking reflex: cr-018 schema: G3 updated: "2026-11-03" translations: fr: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ en: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/ de: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ es: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ sources: - "n": 1 title: Cross Site Request Forgery (CSRF) | OWASP Foundation publisher: OWASP url: https://community.owasp.org/attacks/csrf accessed: "2026-11-03" - "n": 2 title: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core publisher: Microsoft url: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 accessed: "2026-11-03" - "n": 3 title: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html accessed: "2026-11-03" - "n": 4 title: SameSite | OWASP Foundation publisher: OWASP url: https://community.owasp.org/SameSite accessed: "2026-11-03" - "n": 5 title: "CWE - CWE-352: Cross-Site Request Forgery (5.0)" publisher: MITRE url: https://cwe.mitre.org/data/definitions/352.html accessed: "2026-11-03" --- # Le CSRF : l'action forcée à votre insu Le CSRF (Cross-Site Request Forgery) est une attaque qui force un utilisateur à exécuter des actions non voulues sur une application web où il est déjà authentifié [1]. L'attaquant n'a pas besoin du mot de passe de la victime : il fait agir le navigateur de celle-ci. Pour un salarié, le scénario type est simple. Une messagerie ou un site bancaire est ouvert dans un onglet. Un lien reçu par e-mail ou par messagerie instantanée mène vers une autre page, et cette page déclenche, en arrière-plan, une demande vers le service resté connecté [1]. ## En 30 secondes - Où ça arrive : sur la plupart des services web sans protection anti-CSRF, quand vous ouvrez un lien ou une page piégée dans le même navigateur [1]. - Ce que veut l'attaquant : provoquer une action qui modifie quelque chose, comme un virement ou un changement de mot de passe [1]. - Le réflexe : se déconnecter d'un service quand on a fini de s'en servir [2]. - D'où vient la faille : de l'application, pas de l'utilisateur [2]. ## Questions directes ### Le CSRF vole-t-il mon mot de passe ? Non, pas en tant que tel. L'attaque emprunte l'identité et les droits de la victime pour accomplir une action à sa place [1]. Elle vise les actions qui changent l'état du service, comme modifier l'adresse e-mail ou le mot de passe, ou acheter quelque chose. Obliger la victime à consulter des données ne profite pas à l'attaquant, car c'est la victime qui reçoit la réponse, pas lui [1]. ### Pourquoi le service obéit-il à une demande que je n'ai pas voulue ? Parce qu'il ne sait pas la distinguer d'une demande légitime. Pour la plupart des sites, les requêtes du navigateur incluent automatiquement les identifiants associés au site, comme le cookie de session [1]. Si l'utilisateur est authentifié, le site n'a donc aucun moyen de séparer la requête forgée de la requête réelle [1]. Le CWE décrit la faiblesse ainsi : l'application ne vérifie pas, ou ne peut pas vérifier, qu'une requête a été fournie volontairement par l'utilisateur qui l'a envoyée [5]. ### Suis-je protégé si le service est en HTTPS ? Non. D'après OWASP, HTTPS seul ne protège pas du CSRF, même s'il reste un prérequis pour que les autres mesures soient fiables [1]. ### Le problème vient-il de moi ou de l'application ? De l'application. Microsoft le dit en toutes lettres : les failles CSRF sont fondamentalement un problème de l'application web, pas de l'utilisateur final [2]. Les gestes de l'utilisateur limitent seulement l'exposition : se déconnecter quand on a fini et vider régulièrement les cookies du navigateur [2]. ## Dans la peau de l'attaquant L'attaquant commence par repérer une requête qui modifie quelque chose sur un service, puis il fabrique une adresse ou un script qui la reproduit avec ses propres valeurs. OWASP prend l'exemple d'une banque fictive : la requête légitime vire 100 dollars à un bénéficiaire, et l'attaquant remplace le bénéficiaire par lui-même en augmentant le montant [1]. Reste à faire charger cette requête par la victime pendant qu'elle est connectée. Deux méthodes sont citées : un e-mail non sollicité au contenu HTML, ou un piège placé sur des pages que la victime est susceptible de visiter pendant qu'elle utilise son service en ligne [1]. L'attaque peut aussi être stockée sur le site vulnérable lui-même, par exemple dans un champ qui accepte du HTML. Elle devient alors plus probable : la victime consulte plus volontiers une page du site qu'une page quelconque d'Internet, et elle y est forcément déjà connectée [1]. ## Ce que vous voyez à l'écran Souvent, rien. Le lien piégé peut être déguisé en lien ordinaire, avec un texte du genre « voir mes photos ». Il peut aussi prendre la forme d'une fausse image de taille nulle : si elle figure dans un e-mail, la victime ne voit rien, mais le navigateur envoie quand même la requête, sans aucun signe visuel que l'opération a eu lieu [1]. ```text Illustration neutralisée, pas une adresse réelle. Lien déguisé : texte affiché « Voir mes photos », adresse cachée hxxp://banque[.]exemple[.]invalid/virement?dest=[compte de l'attaquant]&montant=[élevé] Variante : image invisible dans un e-mail, chargée sans clic. ``` Si le service attend une requête de type POST, l'attaquant peut héberger sur son site un formulaire aux champs cachés. La victime croit qu'il fait autre chose et clique, ou bien un script l'envoie automatiquement au chargement de la page [1]. Dans les deux cas, la page affichée est banale et l'action se déroule ailleurs. ## Sous le capot Le mécanisme tient à un comportement normal des navigateurs. Ils enregistrent les cookies émis par une application, dont les cookies de session des utilisateurs authentifiés, et ils envoient tous les cookies d'un domaine à chaque requête, quelle que soit la façon dont cette requête est née dans le navigateur [2]. Les cookies ne sont pas seuls en cause : les authentifications de type Basic et Digest sont aussi vulnérables, car le navigateur renvoie automatiquement les identifiants jusqu'à la fin de la session [2]. Plusieurs idées de défense ne fonctionnent pas, selon OWASP [1] : - un cookie secret, puisque tous les cookies sont envoyés avec chaque requête ; - n'accepter que les requêtes POST, puisqu'un formulaire caché suffit à en forger une ; - les transactions en plusieurs étapes, tant que l'attaquant peut prévoir chaque étape ; - la seule vérification de l'en-tête Referer, car il peut être falsifié, et il est parfois absent pour des raisons de confidentialité. Les protections recommandées, côté application, sont les suivantes. - Vérifier d'abord si le cadriciel (framework) offre déjà une protection CSRF, et l'utiliser. À défaut, ajouter des jetons anti-CSRF à toutes les requêtes qui modifient l'état et les valider côté serveur [3]. Sans jeton, l'attaquant ne peut pas fabriquer de requête valide [3]. - Pour les logiciels sans état, utiliser un cookie en double soumission, de préférence signé [3]. - Poser l'attribut SameSite sur les cookies de session [3]. Avec la valeur strict, le navigateur n'envoie pas le cookie sur les requêtes inter-sites, même en suivant un lien ordinaire. Avec lax, il l'envoie pour un lien suivi depuis un autre site mais le retient sur les méthodes exposées au CSRF comme POST [4]. Avec none, aucune protection n'est offerte [4]. - Contrôler l'origine avec les en-têtes standards, notamment Sec-Fetch-Site, pris en charge par tous les grands navigateurs depuis mars 2023 [3]. - Ne pas utiliser de requêtes GET pour des opérations qui modifient l'état [3]. Ces mesures ont des limites. SameSite=Lax laisse passer les requêtes GET de navigation de premier niveau : un point d'accès qui modifie l'état par GET reste vulnérable [2]. Les anciens navigateurs peuvent ne pas appliquer SameSite [2]. Et une faille XSS peut contourner toutes les protections anti-CSRF ; le ver Samy, par exemple, a utilisé un XMLHttpRequest pour obtenir le jeton CSRF et forger des requêtes [1][3]. Le comportement par défaut de SameSite varie : en décembre 2024, lax était la valeur par défaut de Chrome, Edge et Opera, mais d'aucune version de Firefox ni de Safari, d'où le conseil de la fixer explicitement [4]. ## Autopsies ### 2008 : l'exploit uTorrent OWASP cite, comme exemple réel d'attaque CSRF contre une application fonctionnant par requêtes GET, un exploit visant uTorrent datant de 2008. Il a été utilisé à grande échelle pour télécharger des logiciels malveillants [1]. La source n'en dit pas plus : ni le nombre de victimes, ni le mode de diffusion. ### Failles cataloguées par le CWE (identifiants de 2004 à 2009) Le CWE-352 donne une liste choisie d'exemples observés, qui n'est pas exhaustive [5]. Plusieurs reposent sur une simple URL dans une balise img : CVE-2004-1703 et CVE-2004-1995 permettent d'ajouter des comptes utilisateurs, CVE-2004-1842 de gagner des privilèges d'administrateur [5]. D'autres touchent la gestion elle-même : CVE-2009-3520 permet de modifier le mot de passe de l'administrateur, et CVE-2009-3759 de changer des mots de passe ou d'arrêter une machine virtuelle depuis une interface web [5]. ## Sources 1. OWASP, « Cross Site Request Forgery (CSRF) | OWASP Foundation ». https://community.owasp.org/attacks/csrf (consulté le 3 novembre 2026) 2. Microsoft, « Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core ». https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 (consulté le 3 novembre 2026) 3. OWASP, « Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series ». https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (consulté le 3 novembre 2026) 4. OWASP, « SameSite | OWASP Foundation ». https://community.owasp.org/SameSite (consulté le 3 novembre 2026) 5. MITRE, « CWE - CWE-352: Cross-Site Request Forgery (5.0) ». https://cwe.mitre.org/data/definitions/352.html (consulté le 3 novembre 2026) --- Source originale : Cyberpedia, l'encyclopédie publique de cybersécurité et d'IA publiée par Brain. Version canonique : https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ Vous pouvez reprendre ce texte librement sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), à condition de citer « Brain, Cyberpedia » avec un lien vers l'adresse ci-dessus.