SameSite sur les cookies suffit-il à empêcher les attaques CSRF ?

SameSite=Strict ou Lax réduit fortement le risque en empêchant le navigateur d’envoyer les cookies lors de requêtes initiées depuis un autre site. En complément, un token CSRF reste recommandé pour les actions sensibles (changement de mot de passe, virement, modification de compte), car SameSite peut ne pas couvrir tous les cas (navigateurs anciens, requêtes particulières).

Faut-il un token CSRF pour une API REST consommée par une SPA ?

Si la SPA utilise des cookies de session pour l’authentification, oui : les requêtes depuis le navigateur envoient les cookies, une page malveillante pourrait déclencher des requêtes authentifiées. Utilisez un token CSRF (ou un cookie CSRF) et vérifiez-le côté API. Si l’auth est par token (Bearer JWT) stocké en mémoire ou localStorage et envoyé en en-tête, le risque CSRF est réduit (les cookies ne sont pas envoyés automatiquement), mais d’autres bonnes pratiques (CORS, validation) restent nécessaires.

Qu'est-ce que CSRF (Cross-Site Request Forgery) ?

changement de mot de passe, virement, modification de données). L’attaquant exploite le fait que le navigateur envoie automatiquement les cookies de session à chaque requête : une page malveillante peut déclencher une requête POST vers le site cible, avec les cookies de la victime. Contremesures : tokens CSRF (valeur secrète liée à la session, vérifiée côté serveur), SameSite sur les cookies, vérification de l’origine (Origin/Referer). Le token CSRF est en général un secret unique par session (ou par requête) inclus dans le formulaire ou en en-tête ; le serveur le vérifie avant d’exécuter l’action. L’attribut SameSite=Strict ou Lax sur les cookies limite l’envoi des cookies lors de requêtes cross-site, ce qui réduit la surface d’attaque.

Comment ça marche ?

Le serveur génère un token CSRF (secret lié à la session), l'inclut dans le formulaire (champ caché) ou dans un cookie. À la soumission, le serveur vérifie que le token est présent et valide avant d'exécuter l'action. L'attribut SameSite sur les cookies limite l'envoi des cookies en requête cross-site.

L'Impact Business

Une faille CSRF sur des actions sensibles (connexion, formulaire de commande, paramètres compte) peut permettre des prises de contrôle ou des actions frauduleuses. La mise en place de tokens CSRF et de bonnes pratiques cookies est une base de la sécurisation des applications web. Les frameworks modernes (Next.js, Django, Laravel) proposent des mécanismes CSRF intégrés ; les ignorer ou les désactiver sans alternative expose à des risques juridiques et de réputation. Une audit de sécurité inclut systématiquement la vérification des protections CSRF sur les formulaires et les API modifiant des données.

Bonnes pratiques vs Erreurs communes

✅ À faire : Utiliser un token CSRF sur tous les formulaires et API qui modifient des données et utilisent des cookies de session. Configurer SameSite=Strict ou Lax sur les cookies. Vérifier Origin ou Referer en complément. Ne jamais ignorer les mécanismes fournis par le framework.
❌ À éviter : Désactiver la protection CSRF « pour simplifier » ou l'oublier sur des formulaires sensibles (changement de mot de passe, formulaire de commande). Se reposer uniquement sur SameSite sans token pour les actions critiques.

Prompt IA

Contexte : stack [Next.js / Django / Laravel / autre], type d’app [formulaires web / API + SPA]. Explique en 3 étapes le déroulement d’une attaque CSRF. Donne la contremesure recommandée pour cette stack (token CSRF, SameSite, vérification Origin). Fournis un extrait de code : 1) génération et injection du token, 2) vérification côté serveur, 3) configuration des cookies (SameSite). Indique les endpoints à protéger en priorité.