Qu'est-ce que le CSRF et comment les jetons et SameSite l'empêchent-ils ?
Réponse courte
Le CSRF piège le navigateur d'un utilisateur connecté pour lui faire envoyer une requête modifiant l'état vers un site où il est authentifié, en abusant du fait que les cookies sont envoyés automatiquement. On l'empêche avec des jetons anti-CSRF (une valeur secrète par session que l'attaquant ne peut ni lire ni deviner) et l'attribut de cookie SameSite, qui empêche les cookies d'accompagner les requêtes intersites.
La falsification de requête intersite (CSRF) exploite une particularité du web : les navigateurs attachent automatiquement les cookies d'un site à chaque requête vers ce site, y compris les requêtes déclenchées par un site différent. Si un utilisateur est connecté à sa banque puis visite la page d'un attaquant, cette page peut silencieusement déclencher un envoi de formulaire vers la banque — et le navigateur inclut docilement le cookie de session. La banque voit une requête authentifiée et traite le virement. L'attaquant ne lit jamais aucune réponse ; il a seulement besoin que l'action se produise.
Pourquoi l'autorité ambiante est la cause racine
Le CSRF fonctionne parce que l'authentification est ambiante — prouvée par un cookie que le navigateur envoie de lui-même, sans aucune preuve que la requête provient réellement de l'application légitime. Les défenses doivent donc ajouter un signal indiquant que cette requête vient vraiment de notre application.
Jetons anti-CSRF (modèle synchroniseur)
Le serveur intègre un jeton secret, par session et imprévisible dans ses propres formulaires et l'exige en retour sur chaque requête modifiant l'état. La page intersite d'un attaquant ne peut pas lire ce jeton (la Same-Origin Policy bloque la lecture de la réponse qui le contient) et ne peut pas le deviner. La requête falsifiée ne comporte donc pas de jeton valide et est rejetée.
Cookies SameSite
L'attribut de cookie SameSite indique au navigateur quand envoyer le cookie :
- Strict — jamais sur les requêtes intersites (le plus fort, mais peut casser les liens entrants vers des pages connectées).
- Lax — envoyé sur les navigations de premier niveau (clic sur un lien) mais pas sur les POST intersites ni les requêtes de sous-ressources ; un défaut sensé qui bloque le CSRF classique par envoi de formulaire.
- None — toujours envoyé (nécessite
Secure) ; requis pour les contextes intersites légitimes.
L'interaction avec le XSS
Les jetons CSRF supposent que l'attaquant est hors site. Si l'application présente aussi une faille XSS, le script injecté s'exécute sur l'origine et peut lire le jeton — le XSS neutralise donc la protection CSRF. Les deux doivent être corrigés.
Les recruteurs recherchent « envoi automatique des cookies » comme cause racine, l'imprévisibilité du jeton liée à la Same-Origin Policy, la distinction Lax/Strict et la mise en garde sur le XSS.
Questions de suivi probables
- Pourquoi la page CSRF d'un attaquant échoue-t-elle lorsqu'un jeton de synchronisation est requis ?
- Quelle est la différence entre SameSite=Lax et SameSite=Strict ?
- Pourquoi la protection CSRF n'aide-t-elle pas si le site présente aussi une faille XSS ?