Lorsqu’un utilisateur est connecté à un service en ligne, son navigateur conserve des informations d’authentification qui permettent d’interagir facilement avec l’application. Cette facilité, essentielle à l’expérience utilisateur, peut toutefois être détournée. Dans certains cas, une simple interaction avec un contenu externe suffit à déclencher une action non désirée sur un site de confiance, à l’insu de l’utilisateur. C’est précisément sur ce mécanisme que repose l’attaque CSRF. Derrière cet acronyme se cache un type d’attaque web particulièrement efficace, souvent sous-estimé, mais susceptible d’entraîner des conséquences importantes pour la sécurité des applications et la protection des données, ce qui mobilise d’ailleurs la plupart des entreprises de cybersécurité. Que signifie exactement CSRF ? Sur quels principes techniques cette attaque s’appuie-t-elle ? Pourquoi est-elle difficile à détecter et quelles mesures permettent de s’en prémunir ? Cet article propose une définition claire et une analyse complète de cette menace bien réelle du web moderne.

Les origines et le fonctionnement d’une attaque CSRF

CSRF est l’acronyme de Cross-Site Request Forgery, que l’on traduit en français par « falsification de requête inter-sites ». Cette attaque vise à exploiter un comportement fondamental du protocole HTTP et des navigateurs web : l’envoi automatique des informations d’authentification (cookies, en-têtes d’autorisation, sessions) lors de chaque requête vers un domaine donné. Le serveur, de son côté, fait implicitement confiance à ces éléments pour identifier l’utilisateur. Contrairement à d’autres attaques applicatives comme le XSS (Cross-Site Scripting), qui reposent sur l’injection de code malveillant exécuté côté client, l’attaque CSRF ne nécessite aucune compromission directe de l’application cible. Elle exploite une faiblesse logique dans la gestion des requêtes authentifiées. L’attaquant ne cherche pas à voler une session, mais à l’utiliser telle quelle, à l’insu de son propriétaire.

Le principe technique de base est le suivant : lorsqu’un utilisateur est authentifié sur une application web, son navigateur conserve un ou plusieurs cookies de session associés au domaine. Tant que la session est valide, le navigateur Internet joint automatiquement ces cookies à toutes les requêtes HTTP envoyées vers ce domaine, indépendamment de l’origine de la requête (formulaire, image, iframe, script, etc.). Un site tiers, contrôlé par un attaquant, peut alors déclencher une requête HTTP vers l’application cible en incitant le navigateur de la victime à la générer. Cette requête est perçue par le serveur comme légitime, puisqu’elle contient les cookies d’authentification valides. Si l’application ne met pas en place de mécanisme de vérification de l’intention de l’utilisateur, l’action demandée est exécutée. Les attaques CSRF ciblent en priorité les fonctionnalités dites « à effet de bord », c’est-à-dire celles qui modifient l’état du système :

• Changement d’adresse e-mail ou de mot de passe ;
• Ajout ou suppression d’un utilisateur ;
• Validation d’une transaction ou d’un paiement ;
• Modification de paramètres de sécurité ;
• Publication de contenu ou envoi de messages.

Voici un scénario technique simplifié illustrant le fonctionnement d’une attaque CSRF :

1. L’utilisateur est authentifié sur https://banque-en-ligne.fr et dispose d’un cookie de session valide.
2. Sans se déconnecter, il consulte un site tiers contrôlé par un attaquant.
3. Ce site contient une balise HTML ou un script provoquant l’envoi automatique d’une requête HTTP, par exemple :
   <img src="https://banque-en-ligne.fr/virement?montant=1000&dest=pirate" />.
4. Le navigateur envoie la requête GET vers le domaine cible, en y joignant automatiquement les cookies d’authentification.
5. Le serveur de la banque reçoit la requête, valide la session via les cookies et exécute l’action demandée.

D’un point de vue strictement technique, le serveur n’est pas en mesure de distinguer cette requête malveillante d’une requête volontaire émise par l’utilisateur, tant qu’aucun mécanisme de contrôle supplémentaire n’est présent. Le protocole HTTP étant sans état et ne véhiculant pas nativement la notion d’intention utilisateur, la responsabilité de cette vérification repose entièrement sur la logique applicative. Les attaques CSRF peuvent exploiter différents vecteurs techniques :

• Des balises HTML simples (<img>, <iframe>, <link>) ;
• Des formulaires HTML soumis automatiquement ;
• Des requêtes JavaScript utilisant fetch ou XMLHttpRequest (dans certains contextes) ;
• Des liens piégés envoyés par e-mail ou via des messageries.

L’attaque est d’autant plus difficile à détecter qu’elle ne génère généralement aucune anomalie visible pour l’utilisateur. Aucun code malveillant n’est exécuté dans son navigateur, aucune alerte de sécurité n’est déclenchée, et l’action est réalisée dans le cadre d’une session parfaitement valide. Les journaux applicatifs peuvent eux-mêmes ne montrer qu’une requête apparemment normale, émise depuis une session authentifiée.

Ce caractère silencieux fait du CSRF une attaque particulièrement efficace contre les applications web insuffisamment protégées, notamment celles développées sans prise en compte explicite des menaces liées à la sécurité applicative.

Les conditions nécessaires pour une attaque CSRF

Pour qu’une attaque CSRF puisse aboutir, plusieurs conditions techniques doivent être réunies simultanément. Ce caractère cumulatif explique pourquoi ce type d’attaque est à la fois ciblé et particulièrement efficace lorsqu’il exploite une application insuffisamment protégée. L’attaque ne repose pas sur une vulnérabilité unique, mais sur une combinaison de comportements standards du web et de lacunes dans la logique de sécurité applicative.

• Une session authentifiée active : L’utilisateur doit être connecté à l’application cible au moment de l’attaque. Cette session repose généralement sur un cookie de session (ou un jeton stocké dans le navigateur) automatiquement transmis avec chaque requête HTTP vers le domaine concerné. Tant que la session n’a pas expiré ou été invalidée, le serveur considère l’utilisateur comme légitime, indépendamment de l’origine réelle de la requête ;
• Un mécanisme d’authentification basé uniquement sur les cookies : Les attaques CSRF exploitent principalement les schémas d’authentification où le navigateur envoie automatiquement les informations d’identification. Les architectures reposant exclusivement sur des cookies de session sont donc particulièrement exposées si aucune mesure complémentaire n’est mise en place pour vérifier l’intention de l’utilisateur ;
• Une requête vulnérable côté serveur : L’application doit exposer une fonctionnalité permettant de modifier l’état du système (changement de paramètres, action financière, modification de données) sans contrôler la provenance de la requête. Si le serveur se contente de vérifier la validité de la session sans vérifier le contexte d’appel, l’action est exécutable via une requête forgée ;
• Aucune vérification explicite de l’intention utilisateur : En l’absence de mécanismes tels qu’un token CSRF, une confirmation par mot de passe, une validation multi-étapes ou un contrôle strict des en-têtes HTTP, le serveur ne peut pas distinguer une action volontaire d’une requête déclenchée à l’insu de l’utilisateur. Cette absence de preuve d’intention est au cœur de la vulnérabilité CSRF ;
• Une action accessible via une requête HTTP standard : les attaques CSRF exploitent des requêtes GET ou POST simples, facilement déclenchables depuis un site tiers à l’aide de balises HTML (<img>, <form>, <iframe>) ou de scripts. Si une action sensible est accessible sans interaction explicite supplémentaire (clic de confirmation, saisie d’un code), elle devient une cible idéale.

Un facteur aggravant réside dans le fait que l’attaque s’exécute intégralement dans le navigateur de la victime. Aucune information n’est volée, aucun mot de passe n’est intercepté, et aucune alerte de sécurité n’est déclenchée. Le navigateur agit conformément aux règles du protocole HTTP, ce qui rend l’attaque extrêmement discrète et difficile à détecter, tant pour l’utilisateur que pour les systèmes de surveillance. Il est également important de souligner que les mécanismes de sécurité inter-domaines, tels que le CORS (Cross-Origin Resource Sharing), ne constituent pas une protection contre le CSRF. CORS contrôle l’accès aux réponses HTTP par le JavaScript côté client, mais n’empêche pas l’envoi de requêtes elles-mêmes. Les cookies d’authentification sont toujours transmis automatiquement par le navigateur lorsque la requête vise le domaine cible.

De ce fait, une application peut parfaitement respecter les règles CORS tout en restant vulnérable aux attaques CSRF. La protection doit donc être implémentée au niveau applicatif, en ajoutant des contrôles spécifiques permettant de lier chaque action sensible à une intention explicite de l’utilisateur authentifié.

Sans ces mécanismes, toute application web exposant des fonctionnalités critiques s’appuie uniquement sur une confiance implicite accordée au navigateur, ouvrant la voie à des attaques CSRF efficaces, silencieuses et potentiellement lourdes de conséquences.

Comment se protéger efficacement contre les attaques CSRF

La protection contre les attaques CSRF repose essentiellement sur des mesures mises en œuvre côté serveur, complétées par certaines configurations côté client. Contrairement à d’autres menaces, l’utilisateur final n’a que très peu de moyens d’action : c’est donc à l’application elle-même de prouver que chaque requête sensible correspond bien à une intention explicite de l’utilisateur authentifié. Une stratégie de défense efficace repose sur la combinaison de plusieurs mécanismes. Aucun dispositif isolé ne suffit à garantir une protection totale, mais leur cumul permet de réduire considérablement la surface d’attaque.

1. Utiliser des jetons CSRF (anti-CSRF token)

Le mécanisme de protection le plus répandu repose sur l’utilisation de jetons CSRF, également appelés anti-CSRF tokens. Il s’agit de valeurs aléatoires, imprévisibles et uniques, générées par le serveur et associées à la session de l’utilisateur (ou à une action précise). Ces jetons sont intégrés dans chaque formulaire HTML ou ajoutés aux requêtes HTTP modifiant l’état de l’application. Lors de la réception de la requête, le serveur compare le jeton fourni avec celui attendu pour la session en cours. Si le jeton est absent, incorrect ou expiré, la requête est rejetée. D’un point de vue technique, ce mécanisme repose sur le fait qu’un site tiers ne peut pas lire ou deviner le jeton CSRF, car il est généré côté serveur et transmis uniquement dans le contexte du site légitime. Exemple d’un formulaire HTML protégé :

<form action="/modifier-email" method="POST">
  <input type="email" name="email" />
  <input type="hidden" name="csrf_token" value="abc123xyz" />
  <input type="submit" value="Changer l'email" />
</form>

Il existe plusieurs implémentations reconnues de ce principe, notamment :

• le synchronizer token pattern, où le jeton est stocké côté serveur ;
• le double submit cookie, où le jeton est stocké à la fois dans un cookie et dans la requête ;
• les protections intégrées aux frameworks modernes (Spring Security, Django, Laravel, Rails, etc.).

2. Vérifier l’en-tête HTTP Origin ou Referer

Une mesure complémentaire consiste à vérifier les en-têtes HTTP Origin ou Referer afin de s’assurer que la requête provient bien du domaine attendu. Si l’origine déclarée ne correspond pas à celle de l’application, la requête peut être bloquée. D’un point de vue technique, cette approche permet de détecter certaines requêtes inter-sites, notamment celles générées depuis des pages externes. Toutefois, elle présente plusieurs limites :

• les en-têtes peuvent être absents ou tronqués pour des raisons de confidentialité ;
• certains environnements ou proxies modifient ces valeurs ;
• elle ne constitue pas une preuve cryptographique de l’intention utilisateur.

Pour ces raisons, cette vérification doit être considérée comme une défense additionnelle, et non comme un mécanisme principal de protection contre le CSRF.

3. Ne pas autoriser les requêtes d’état via GET

Les requêtes HTTP GET sont conçues pour être idempotentes et sans effet de bord. Elles peuvent être déclenchées automatiquement par le navigateur dans de nombreux contextes (chargement d’images, préchargement de liens, crawlers, etc.). Exposer des actions sensibles via GET augmente donc considérablement les risques de CSRF. Les bonnes pratiques imposent que toute action modifiant l’état de l’application utilise des méthodes HTTP adaptées :

• POST pour la création ou la modification de données ;
• PUT ou PATCH pour les mises à jour ;
• DELETE pour les suppressions.

Cette séparation ne suffit pas à elle seule à empêcher une attaque CSRF, mais elle limite fortement les vecteurs exploitables et facilite la mise en place de contrôles de sécurité adaptés.

4. Déconnecter les sessions inactives automatiquement

La durée de vie des sessions joue un rôle important dans la réduction du risque CSRF. Plus une session reste active longtemps, plus la fenêtre d’exploitation est large pour un attaquant. Limiter la durée d’inactivité autorisée, invalider les sessions anciennes et forcer une réauthentification pour les opérations sensibles permettent de réduire l’impact potentiel d’une attaque. Certaines applications exigent également une confirmation supplémentaire (mot de passe, code à usage unique) avant d’exécuter des actions critiques. Cette approche ne bloque pas directement le CSRF, mais elle en limite les effets dans le temps et réduit la probabilité de succès.

5. Mettre en place des politiques de sécurité côté client

Les navigateurs modernes offrent des mécanismes supplémentaires pour limiter l’envoi automatique des cookies dans des contextes inter-domaines. L’attribut SameSite des cookies permet de contrôler leur inclusion dans les requêtes cross-site :

• SameSite=Strict : les cookies ne sont jamais envoyés lors de requêtes provenant d’un site tiers ;
• SameSite=Lax : les cookies sont envoyés uniquement dans certains cas limités (navigation directe) ;
• SameSite=None : les cookies sont envoyés dans tous les contextes, sous réserve d’utiliser HTTPS.

Configurer correctement SameSite permet de bloquer de nombreuses attaques CSRF sans modifier la logique applicative. Toutefois, cette protection dépend du support navigateur et ne doit pas être utilisée comme unique mécanisme de défense.

En pratique, la protection contre les attaques CSRF repose sur une approche en profondeur, combinant jetons anti-CSRF, validation côté serveur, bonnes pratiques HTTP et configuration stricte des cookies. Cette combinaison permet de garantir que chaque action sensible exécutée par l’application résulte bien d’une intention explicite et légitime de l’utilisateur authentifié.