CSRF : cookies SameSite et jetons
Comprenez comment la falsification de requête intersite exploite les cookies, utilisez SameSite=Strict/Lax pour l’empêcher et ajoutez des jetons synchronisés pour renforcer la protection.
CSRF : cookies SameSite et jetons est une leçon Frontend Academy gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Frontend Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Frontend Academy comprend 4 leçons au total.
Qu'est-ce que le CSRF ?
Falsification de requête intersite : un attaquant incite le navigateur d'un utilisateur authentifié à envoyer une requête à votre site. Le navigateur joint les cookies de l'utilisateur — le serveur pense qu'il s'agit d'une requête légitime envoyée par cet utilisateur.
Attaque CSRF classique
L'utilisateur est connecté à bank.com. Il consulte evil.com. evil.com envoie un formulaire masqué à bank.com/transfer avec le numéro de compte de l'attaquant. Le navigateur envoie automatiquement le cookie de session de bank.com. Le serveur transfère l'argent.
Le problème de confiance
Le CSRF fonctionne parce que les navigateurs incluent automatiquement les cookies dans les requêtes entre origines. Sans protection supplémentaire, le serveur ne peut pas savoir que la requête vient d'un site malveillant.
Les cookies SameSite — la solution moderne
L'attribut de cookie SameSite contrôle le moment où les cookies sont envoyés dans les requêtes entre origines. Strict : jamais envoyé entre origines. Lax (valeur par défaut dans Chrome) : envoyé uniquement lors d'une navigation GET de premier niveau. None : toujours envoyé (l'attribut Secure doit également être défini).
Set-Cookie: session=abc; HttpOnly; Secure; SameSite=LaxValeur SameSite=Lax par défaut
Si aucun attribut SameSite n'est spécifié, Chrome définit par défaut tous les cookies sur Lax. Cela bloque la plupart des attaques CSRF — mais vous devriez tout de même le spécifier explicitement.
SameSite=Strict pour une sécurité maximale
Utilisez Strict pour les cookies les plus sensibles (sessions d'administration, transactions bancaires). Inconvénient : l'utilisateur semble déconnecté lorsqu'il arrive via un lien provenant d'un autre site.
Tokens CSRF (modèle synchroniseur)
Pour prendre en charge les anciens navigateurs ou renforcer la sécurité, utilisez des token CSRF. Le serveur génère un token aléatoire, l'intègre à la page et l'exige dans chaque requête qui modifie l'état.
// Server embeds token in HTML or sets it as a non-HttpOnly cookie:
<meta name="csrf-token" content="a1b2c3...">
// Client reads token and sends in header:
const token = document.querySelector('meta[name=csrf-token]').content;
fetch('/transfer', {
method: 'POST',
headers: { 'X-CSRF-Token': token },
body: JSON.stringify({ amount: 100 })
});
// Server verifies the X-CSRF-Token header matches the user's sessionCookie à double soumission
Le serveur définit un cookie CSRF (non-HttpOnly afin que JS puisse le lire). Le client le lit et envoie sa valeur dans un en-tête. Le serveur vérifie que le cookie correspond à l'en-tête. Un attaquant ne peut pas lire le cookie depuis une autre origine et ne peut donc pas reproduire l'en-tête.
Pourquoi cela fonctionne
Le evil.com de l'attaquant ne peut pas lire les cookies de bank.com (politique de même origine). Il ne peut donc pas définir l'en-tête X-CSRF-Token. La requête échoue lors de la vérification du token sur le serveur.
CSRF dans les SPA avec des tokens Bearer
Si vous vous authentifiez avec Authorization: Bearer <jwt> stocké en mémoire (et non dans un cookie), le CSRF ne s'applique pas : les navigateurs n'envoient pas automatiquement les en-têtes. En contrepartie, cette approche est plus vulnérable aux XSS (les tokens accessibles à JS peuvent être volés).
Astuce de l'en-tête personnalisé
Pour les API qui n'acceptent que du JSON avec un en-tête personnalisé (par exemple X-Requested-With), les navigateurs envoient une requête OPTIONS de pré-vérification — et n'y incluent pas les cookies. Cela bloque de fait le CSRF fondé sur des formulaires simples.
Points de terminaison idempotents ou modificateurs
Le CSRF concerne principalement les requêtes qui modifient l'état (POST, PUT, DELETE). Les points de terminaison GET doivent être idempotents — ne produire aucun effet de bord — afin qu'un GET falsifié ne puisse pas causer de dommages.
Vérification rapide
Quelle valeur du cookie SameSite empêche par défaut l'envoi des cookies dans la plupart des requêtes intersites des navigateurs modernes ?
Récapitulatif : prévention du CSRF
Définissez SameSite=Lax (ou Strict) sur les cookies de session — cela bloque la plupart des attaques CSRF. Ajoutez HttpOnly et Secure. Utilisez des token CSRF (modèle synchroniseur ou cookie à double soumission) pour une protection supplémentaire. Les tokens Bearer dans les en-têtes évitent le CSRF, mais augmentent le risque de XSS. L'astuce de l'en-tête personnalisé force une requête de pré-vérification. Rendez les requêtes GET idempotentes.
Apprends HTML avec un tuteur IA — gratuit
Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.
- Cours
- 41
- Leçons
- 163
Questions Fréquemment Posées
La leçon « CSRF : cookies SameSite et jetons » est-elle gratuite ?
Oui — le texte complet de « CSRF : cookies SameSite et jetons » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Frontend Academy, passe à CoddyKit PRO. Le cours Frontend Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « CSRF : cookies SameSite et jetons » ?
Comprenez comment la falsification de requête intersite exploite les cookies, utilisez SameSite=Strict/Lax pour l’empêcher et ajoutez des jetons synchronisés pour renforcer la protection. Tu pratiques Frontend Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Frontend Academy ?
Aucune expérience préalable n'est requise. Frontend Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.
Combien de temps prend la leçon « CSRF : cookies SameSite et jetons » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Frontend Academy ?
Oui. Chaque leçon Frontend Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Prévention des XSS : encodage de sortie et CSP
- CSRF : cookies SameSite et jetons
- Content Security Policy : nonce et hachage
- Flux OAuth côté frontend