CSRF : comparer les protections avant de sécuriser une application métier

Une application métier peut être correctement protégée par un mot de passe et une authentification multifacteur, puis accepter malgré tout une action déclenchée depuis un autre site. Le problème apparaît lorsque le navigateur joint automatiquement les cookies de session à une requête envoyée vers l’application. Si le serveur ne vérifie pas que la demande vient bien de l’interface attendue, une modification d’adresse, de coordonnées bancaires ou de préférences peut être tentée à l’insu de l’utilisateur.

Cette attaque porte le nom de CSRF, pour Cross-Site Request Forgery, ou falsification de requête intersites. Pour une PME, le sujet n’est pas de choisir le mécanisme le plus sophistiqué en général. Il faut relier la protection au mode d’authentification, aux actions exposées, aux clients utilisés et aux preuves que l’équipe pourra produire avant la mise en production.

Le point de départ : quelles actions le navigateur peut-il authentifier ?

Un CSRF concerne principalement les actions qui changent un état : créer un utilisateur, modifier une commande, enregistrer un bénéficiaire, changer une adresse ou déclencher un traitement. Le risque est particulièrement lisible lorsque l’application s’appuie sur une session conservée dans un cookie, car ce cookie peut être envoyé sans que l’utilisateur recopie une information dans chaque formulaire.

La première vérification consiste donc à inventorier les routes qui modifient des données, y compris celles qui ne sont pas visibles comme des formulaires classiques. Une ancienne route acceptant une requête GET pour effectuer une modification mérite d’être corrigée : une consultation ne devrait pas produire d’effet métier. Ce changement réduit l’exposition, mais ne remplace pas un contrôle CSRF sur les requêtes qui modifient réellement l’état.

Il faut aussi distinguer CSRF et vol de session. Dans un CSRF, l’attaquant n’a pas nécessairement besoin de lire la réponse ni de connaître le cookie de la victime : il cherche à faire exécuter une requête authentifiée. À l’inverse, un script malveillant exécuté dans l’origine de l’application peut souvent agir comme l’utilisateur et contourner un jeton CSRF. La protection contre les scripts injectés reste donc nécessaire.

Quatre approches à comparer avant de choisir

Le jeton synchronisé est souvent le choix le plus lisible pour une application web rendue côté serveur. Un jeton peut être injecté dans les formulaires et transmis dans un en-tête pour les appels JavaScript. Le serveur le compare à la valeur attendue pour la session avant d’accepter l’opération. L’intérêt n’est pas seulement technique : le mécanisme est vérifiable dans une revue de code et dans une recette fonctionnelle.

Le double cookie peut convenir à une application dont le serveur et le client sont séparés, à condition de traiter sérieusement la création, la signature et la portée du cookie. Une comparaison de valeurs non liée à la session et un cookie trop largement partagé peuvent donner une fausse impression de protection. Le choix doit donc être documenté avec le modèle de menace retenu.

Les contrôles Origin ou Referer et l’attribut SameSite sont utiles comme couches complémentaires. Ils deviennent particulièrement intéressants lorsqu’une équipe veut bloquer rapidement une partie des requêtes inattendues tout en conservant un jeton pour les opérations les plus sensibles. En revanche, une politique de partage entre plusieurs sous-domaines ou une intégration avec un fournisseur tiers peut rendre le comportement moins évident.

Le bon choix dépend aussi du type de client

Une application web classique, un front-end monopage et une API ne présentent pas exactement la même surface. Un front-end qui utilise une session dans un cookie reste concerné, même si les appels sont effectués en JavaScript. À l’inverse, un service qui reçoit un jeton dans l’en-tête Authorization et qui ne le récupère pas automatiquement depuis un cookie n’est pas exposé de la même manière au CSRF classique.

Cette distinction ne justifie pas une conclusion automatique. Il faut vérifier où le jeton est conservé, quels appels sont faits par le navigateur, si des cookies sont utilisés pour l’authentification et si une politique CORS autorise des requêtes avec identifiants depuis d’autres origines. Une configuration CORS trop permissive peut annuler le bénéfice recherché par un en-tête personnalisé.

Pour une PME, la décision peut être résumée ainsi :

• session par cookie et formulaires serveur : jeton synchronisé, avec contrôle d’origine et SameSite en complément ;
• front-end séparé utilisant une session par cookie : jeton transmis dans un en-tête, contrôle CORS strict et vérification de l’origine ;
• API appelée avec un jeton qui n’est pas automatiquement joint par le navigateur : vérifier malgré tout les cookies, les redirections et les routes historiques ;
• intégration avec plusieurs domaines : documenter les origines autorisées et tester les parcours réels avant de relâcher une règle.

Chronologie de mise en place pour éviter les angles morts

1. Jour 1 : cartographier les opérations qui modifient des données, leurs méthodes HTTP, leur mode d’authentification et leurs clients.

2. Jour 2 : choisir un mécanisme par famille d’interface, puis nommer la responsabilité de son intégration dans les formulaires, les composants et les appels internes.

3. Jour 3 : traiter les exceptions visibles : routes anciennes, appels asynchrones, formulaires multi-étapes, sous-domaines et opérations déclenchées par des liens.

4. Avant la recette : vérifier qu’une requête sans jeton, avec un jeton périmé ou provenant d’une origine non autorisée est refusée sans effet métier.

5. Après la correction : conserver les routes couvertes, les cas refusés et la décision de sécurité dans les livrables du projet.

La preuve attendue vaut mieux qu’une case cochée

Une protection CSRF ne se résume pas à la présence d’un champ caché dans une page. Il faut montrer que le serveur refuse réellement les variantes dangereuses et que le contrôle s’applique aux actions importantes. Une recette utile comprend au moins une requête valide, une requête sans jeton, une valeur incorrecte, une origine inattendue et un scénario avec plusieurs onglets ou une session renouvelée.

Le résultat doit rester compréhensible par le décideur : quelles opérations sont couvertes, quelle règle s’applique à chacune, qui maintient le mécanisme et que se passe-t-il lorsqu’un contrôle échoue ? Une évaluation de sécurité applicative proportionnée peut compléter cette vérification lorsque l’application est exposée ou qu’elle manipule des opérations à fort impact.

Les logs doivent éviter de conserver les jetons eux-mêmes. Ils peuvent toutefois enregistrer un refus, une route concernée, un identifiant de corrélation et une information limitée sur l’origine du contrôle, selon les règles de minimisation retenues. Une journalisation applicative exploitable aide alors à distinguer une attaque, une mauvaise intégration du front-end et une session devenue invalide.

La décision à prendre

Pour une application métier authentifiée par cookie, le jeton CSRF reste généralement le socle le plus explicite. SameSite, Origin ou Referer renforcent la défense, mais ne doivent pas masquer les routes oubliées, les exceptions CORS ou les interfaces historiques. Le choix final doit tenir dans une matrice simple : mécanisme retenu, opérations couvertes, responsable, scénario de refus et preuve attendue.

Cette approche évite deux erreurs opposées : croire qu’un attribut de cookie suffit partout, ou déployer une mécanique complexe sans savoir quelles actions elle protège réellement. La sécurité devient exploitable lorsque chaque contrôle est relié à une décision métier et à un résultat de recette vérifiable.