Activer CORS vous protège-t-il du CSRF ?
Réponse courte
Non. CORS n'est pas une défense contre le CSRF : il assouplit en réalité la politique de même origine pour qu'une page puisse lire des réponses cross-origin qu'elle ne pourrait pas lire autrement. Le CSRF n'a pas besoin de lire la réponse ; il a juste besoin que le navigateur de la victime envoie une requête authentifiée qui modifie l'état. Les vraies défenses sont les jetons anti-CSRF, l'attribut de cookie SameSite, et la vérification d'Origin/Referer.
C'est un piège de niveau senior parce que les deux acronymes semblent liés et impliquent tous deux le « cross-origin ». Beaucoup d'ingénieurs supposent que CORS est un mur de sécurité. En réalité, CORS assouplit un mur, et il traite un problème différent de celui du CSRF.
Ce que fait réellement CORS
La politique de même origine empêche normalement le JavaScript du site A de lire la réponse d'une requête vers le site B. CORS est le mécanisme par lequel le site B peut autoriser explicitement le site A à lire ses réponses. CORS consiste donc à assouplir des restrictions de lecture, pas à bloquer des requêtes. Une configuration CORS restrictive signifie simplement que d'autres origines ne peuvent pas lire vos réponses ; elle ne fait rien pour empêcher une requête d'être envoyée.
Pourquoi le CSRF s'en moque
Une attaque CSRF s'appuie sur la session déjà authentifiée de la victime. La page de l'attaquant déclenche une requête modifiant l'état (virer des fonds, changer l'e-mail) et le navigateur attache automatiquement les cookies de la victime. L'attaquant n'a jamais besoin de lire la réponse : le dommage est causé par l'effet de bord. Beaucoup de ces requêtes (un simple POST de formulaire, un GET d'image) sont des « requêtes simples » qui ne déclenchent même pas de pré-vérification CORS. Donc CORS, qui ne régit que la lecture, est sans rapport avec l'attaque. Le distracteur « arrête GET mais pas POST » se méprend totalement sur le fonctionnement.
Les vraies défenses
- Jetons anti-CSRF : un jeton imprévisible par session/par requête que l'attaquant ne peut pas deviner.
- Cookies SameSite (Lax/Strict) : le navigateur retient le cookie sur les requêtes cross-site.
- Validation d'Origin/Referer sur les points de terminaison modifiant l'état.
Ce que recherchent les recruteurs
Un « non » clair, la distinction lecture/envoi, et les bonnes mesures d'atténuation. Confondre CORS avec une défense CSRF est une erreur courante et révélatrice.
Questions de suivi probables
- Quelle est la différence entre ce que CORS contrôle et ce que la politique de même origine impose ?
- Comment l'attribut de cookie SameSite atténue-t-il le CSRF, et quelles sont ses limites ?
- Pourquoi un simple POST de formulaire est-il un risque CSRF même avec une configuration CORS restrictive ?