CSRF : comprendre la falsification de requête
La CSRF (Cross-Site Request Forgery) pousse un utilisateur authentifié à exécuter, à son insu, une action sur une application web. Une faille discrète mais aux conséquences parfois lourdes, heureusement simple à corriger quand on la connaît.
Qu'est-ce qu'une vulnérabilité CSRF ?
Une faille CSRF détourne la relation de confiance entre un navigateur et un serveur. L'objectif de l'attaquant : forcer un utilisateur déjà authentifié à effectuer une action précise sans s'en rendre compte : changer un mot de passe, modifier des informations personnelles, valider une opération sensible.
Concrètement, l'attaquant piège la victime pour qu'elle charge une page malveillante. Cette page émet alors des requêtes via le navigateur de la victime, comme s'il s'agissait d'actions légitimes. Si la victime dispose de droits d'administration, c'est toute l'application qui peut être compromise. Pour augmenter ses chances, l'attaquant s'appuie souvent sur l'ingénierie sociale, par exemple un lien envoyé par phishing.
Particularité : la CSRF vise généralement des requêtes de modification (et non le vol direct de données), car l'attaquant ne voit pas la réponse à la requête falsifiée. Elle reste un maillon classique des scénarios de vol de compte.
Quelles conditions pour qu'une attaque CSRF réussisse ?
Authentification par cookie seul
L'application s'appuie uniquement sur les cookies pour authentifier l'utilisateur : le navigateur les renvoie automatiquement, même pour une requête déclenchée par un site tiers.
Des paramètres prévisibles
Les requêtes sensibles ne contiennent aucune valeur imprévisible : tous leurs paramètres peuvent être devinés ou reconstitués par l'attaquant.
Des fonctions intéressantes à cibler
L'application expose des actions à fort enjeu : changement de mot de passe, modification de données, opérations liées à des droits élevés.
Un utilisateur piégé
La victime, déjà connectée, est amenée à charger une page malveillante, souvent via un lien d'apparence anodine reçu par e-mail ou message.
Deux parades efficaces
Bonne nouvelle : la CSRF est relativement simple à contrer. Deux mesures se combinent. Le jeton anti-CSRF : une valeur unique et aléatoire générée côté serveur et exigée à chaque requête sensible, impossible à deviner pour l'attaquant. De nombreux frameworks (Django, Laravel…) l'intègrent par défaut. L'attribut SameSite sur les cookies : il empêche l'envoi des cookies de session lorsqu'une requête ne provient pas du domaine de l'application. Attention toutefois : SameSite ne gère pas les sous-domaines, ce qui peut laisser une brèche si un sous-domaine est compromis.
Vérifier, plutôt que supposer
Une protection « activée par défaut » n'est pas toujours appliquée partout : une route oubliée, une API exposée ou une configuration SameSite trop permissive suffisent à rouvrir la faille. La seule façon d'en avoir le cœur net est de tester réellement les fonctions sensibles, dans le cadre d'un test d'intrusion ou d'une démarche de sécurité applicative.
Se protéger, étape par étape
Activer les jetons anti-CSRF
Sur toutes les actions de modification : un jeton unique et imprévisible par requête, vérifié côté serveur.
Configurer l'attribut SameSite
Sur les cookies de session, pour bloquer les requêtes initiées depuis un autre domaine, en tenant compte des sous-domaines.
S'appuyer sur les protections du framework
Vérifier que les middlewares anti-CSRF sont bien actifs partout, et ne pas les désactiver « pour aller plus vite ».
Tester les fonctions sensibles
Un pentest confirme que les parcours critiques sont réellement protégés, y compris sur les API.
Sensibiliser aux liens piégés
La CSRF démarre souvent par un clic. La sensibilisation réduit la probabilité de déclenchement.
Auditer régulièrement
Les audits de sécurité périodiques détectent les régressions introduites au fil des évolutions.
Pourquoi se faire accompagner par BCIT ?
Des tests concrets
Nous éprouvons réellement vos fonctions sensibles plutôt que de nous fier aux protections « par défaut ».
Des correctifs clairs
Des recommandations directement applicables par vos équipes de développement, hiérarchisées par impact.
Une vision d'ensemble
De la sécurité du site aux audits, nous couvrons la chaîne complète.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos fonctions sensibles sont-elles vraiment protégées ?
Prenons 15 minutes pour faire le point sur l'exposition de vos applications aux attaques CSRF et définir les vérifications prioritaires.
CSRF : comprendre la falsification de requête
La CSRF (Cross-Site Request Forgery) pousse un utilisateur authentifié à exécuter, à son insu, une action sur une application web. Une faille discrète mais aux conséquences parfois lourdes, heureusement simple à corriger quand on la connaît.
Qu'est-ce qu'une vulnérabilité CSRF ?
Une faille CSRF détourne la relation de confiance entre un navigateur et un serveur. L'objectif de l'attaquant : forcer un utilisateur déjà authentifié à effectuer une action précise sans s'en rendre compte : changer un mot de passe, modifier des informations personnelles, valider une opération sensible.
Concrètement, l'attaquant piège la victime pour qu'elle charge une page malveillante. Cette page émet alors des requêtes via le navigateur de la victime, comme s'il s'agissait d'actions légitimes. Si la victime dispose de droits d'administration, c'est toute l'application qui peut être compromise. Pour augmenter ses chances, l'attaquant s'appuie souvent sur l'ingénierie sociale, par exemple un lien envoyé par phishing.
Particularité : la CSRF vise généralement des requêtes de modification (et non le vol direct de données), car l'attaquant ne voit pas la réponse à la requête falsifiée. Elle reste un maillon classique des scénarios de vol de compte.
Quelles conditions pour qu'une attaque CSRF réussisse ?
Authentification par cookie seul
L'application s'appuie uniquement sur les cookies pour authentifier l'utilisateur : le navigateur les renvoie automatiquement, même pour une requête déclenchée par un site tiers.
Des paramètres prévisibles
Les requêtes sensibles ne contiennent aucune valeur imprévisible : tous leurs paramètres peuvent être devinés ou reconstitués par l'attaquant.
Des fonctions intéressantes à cibler
L'application expose des actions à fort enjeu : changement de mot de passe, modification de données, opérations liées à des droits élevés.
Un utilisateur piégé
La victime, déjà connectée, est amenée à charger une page malveillante, souvent via un lien d'apparence anodine reçu par e-mail ou message.
Deux parades efficaces
Bonne nouvelle : la CSRF est relativement simple à contrer. Deux mesures se combinent. Le jeton anti-CSRF : une valeur unique et aléatoire générée côté serveur et exigée à chaque requête sensible, impossible à deviner pour l'attaquant. De nombreux frameworks (Django, Laravel…) l'intègrent par défaut. L'attribut SameSite sur les cookies : il empêche l'envoi des cookies de session lorsqu'une requête ne provient pas du domaine de l'application. Attention toutefois : SameSite ne gère pas les sous-domaines, ce qui peut laisser une brèche si un sous-domaine est compromis.
Vérifier, plutôt que supposer
Une protection « activée par défaut » n'est pas toujours appliquée partout : une route oubliée, une API exposée ou une configuration SameSite trop permissive suffisent à rouvrir la faille. La seule façon d'en avoir le cœur net est de tester réellement les fonctions sensibles, dans le cadre d'un test d'intrusion ou d'une démarche de sécurité applicative.
Se protéger, étape par étape
Activer les jetons anti-CSRF
Sur toutes les actions de modification : un jeton unique et imprévisible par requête, vérifié côté serveur.
Configurer l'attribut SameSite
Sur les cookies de session, pour bloquer les requêtes initiées depuis un autre domaine, en tenant compte des sous-domaines.
S'appuyer sur les protections du framework
Vérifier que les middlewares anti-CSRF sont bien actifs partout, et ne pas les désactiver « pour aller plus vite ».
Tester les fonctions sensibles
Un pentest confirme que les parcours critiques sont réellement protégés, y compris sur les API.
Sensibiliser aux liens piégés
La CSRF démarre souvent par un clic. La sensibilisation réduit la probabilité de déclenchement.
Auditer régulièrement
Les audits de sécurité périodiques détectent les régressions introduites au fil des évolutions.
Pourquoi se faire accompagner par BCIT ?
Des tests concrets
Nous éprouvons réellement vos fonctions sensibles plutôt que de nous fier aux protections « par défaut ».
Des correctifs clairs
Des recommandations directement applicables par vos équipes de développement, hiérarchisées par impact.
Une vision d'ensemble
De la sécurité du site aux audits, nous couvrons la chaîne complète.
Pas encore prêt à échanger ? Découvrez notre diagnostic cybersécurité →
Vos fonctions sensibles sont-elles vraiment protégées ?
Prenons 15 minutes pour faire le point sur l'exposition de vos applications aux attaques CSRF et définir les vérifications prioritaires.