CSRF

CSRF (Cross-Site Request Forgery) est une attaque où un site malveillant amène le navigateur d’une victime à émettre une requête authentifiée contre un site cible, exploitant les cookies que le navigateur attache automatiquement.

Exemple classique : vous êtes connecté à bank.example.com. Vous visitez evil.example, qui contient <img src="https://bank.example.com/transfer?to=attacker&amount=1000" />. Votre navigateur envoie dûment la requête avec vos cookies de session bancaire. La banque, incapable de distinguer l’origine légitime, traite le virement.

Défenses modernes :

• Attribut cookie SameSite (Lax par défaut dans les navigateurs modernes) — bloque les cookies sur les requêtes POST cross-origin.
• Tokens CSRF — tokens aléatoires émis par le serveur inclus dans les formulaires, vérifiés à la soumission. Standard industriel depuis des décennies.
• Validation des en-têtes Origin/Referer — défense en profondeur.
• Authentification par token Bearer (dans les en-têtes, pas dans les cookies) — immunisée contre CSRF par défaut.

Les frameworks modernes (Django, Rails, Spring) livrent la protection CSRF activée par défaut. Le changement de cookie Lax par défaut en 2020 a effectivement éliminé CSRF pour la plupart des applications modernes sans aucun changement de code.

Exemple concret

Une vulnérabilité de 2008 dans de nombreux routeurs domestiques illustre l’attaque classique. L’interface d’administration du routeur se trouvait à http://192.168.1.1/, utilisait des cookies d’authentification basique, et exposait un formulaire comme POST /apply.cgi?dns=... pour changer le serveur DNS. Un attaquant contrôlait un site web séparé qui incluait un formulaire invisible à soumission automatique ciblant cette URL. Un utilisateur connecté visitant la page malveillante verrait son navigateur envoyer silencieusement le formulaire POST à son routeur, avec les cookies d’authentification attachés automatiquement, et le DNS serait remplacé par celui de l’attaquant. Du point de vue du routeur, chaque requête semblait légitime. La solution retenue par l’industrie : ajouter un token CSRF par session au formulaire, le valider à la soumission, et rejeter les requêtes où le token est manquant ou incorrect. Une deuxième solution est arrivée avec les cookies SameSite=Lax dans Chrome 80 (2020) — le navigateur cesse d’envoyer des cookies sur les POST cross-site, déjouant l’attaque au niveau des cookies indépendamment des vérifications côté serveur.

Quand et pourquoi c’est important

CSRF importe chaque fois qu’une application authentifie les utilisateurs via des cookies que le navigateur attache automatiquement — ce qui représente la plupart des applications web héritées et beaucoup de modernes. L’erreur est de supposer que “nous sommes une API, CSRF ne s’applique pas” : si l’API utilise des cookies de session (plutôt que des tokens Bearer) et accepte des POST form-encodés ou des POST JSON simples sans preflight, elle est vulnérable. La deuxième erreur est de se fier uniquement à l’en-tête Referer — beaucoup de proxies d’entreprise et d’outils de confidentialité le suppriment, bloquant les utilisateurs légitimes. Le minimum moderne pour une application basée sur les cookies : définir SameSite=Lax (ou Strict pour les endpoints sensibles) sur tous les cookies d’authentification, valider un token CSRF sur chaque requête modifiant l’état, et rejeter les requêtes avec des en-têtes Origin non correspondants sur les endpoints JSON. Pour les nouvelles API, passer entièrement à l’authentification par token Bearer via l’en-tête Authorization et la surface d’attaque disparaît. Référence : OWASP — Cross-Site Request Forgery.

Le schéma double-submit cookie : quand un backend ne peut pas stocker d’état par session, le token CSRF peut être émis via un cookie et doit également apparaître dans un en-tête de requête personnalisé. Le navigateur attache automatiquement le cookie à chaque requête, mais les sites cross-origin ne peuvent pas lire sa valeur pour la copier dans l’en-tête — la politique de même origine bloque la lecture. Le serveur compare les deux et rejette les non-correspondances. C’est la technique que la plupart des frameworks modernes d’application monopages (Angular, configuration par défaut d’Axios) utilisent pour la défense CSRF sur les API JSON.

Pourquoi CSRF devient de plus en plus irrelevant : la combinaison des valeurs par défaut SameSite=Lax (Chrome 80, 2020), de l’authentification par token Bearer, et du preflight CORS sur les requêtes non-simples a réduit la surface d’attaque pratique aux endpoints form-encodés héritées qui s’appuient encore sur les cookies. Pour les nouvelles API construites aujourd’hui, sortir entièrement des cookies et utiliser les en-têtes Authorization: Bearer <token> élimine CSRF sans cérémonie. OWASP a retiré CSRF du Top 10 en 2017 en raison de la généralisation des défenses structurelles. Référence : OWASP CSRF Prevention Cheat Sheet.