🛡️
securite

CSRF

Attaque qui force un utilisateur authentifie à exécuter des actions non souhaitees.

Définition

CSRF (Cross-Site Request Forgery), aussi appele "session riding", est une attaque web qui force un utilisateur authentifie à exécuter des actions non souhaitees sur un site ou il est connecte.

L'attaquant exploite le fait que le navigateur envoie automatiquement les cookies de session avec chaque requête vers un domaine donne.

Comment fonctionne l'attaque ?

  1. Alice est connectee à sa banque (banque.com) — son cookie de session est actif
  2. Alice visite un site malveillant qui contient :
<!-- Sur le site malveillant -->
<img src="https://banque.com/virement?montant=10000&destinataire=attaquant" />
  1. Le navigateur d'Alice envoie la requête a banque.com avec son cookie de session
  2. La banque execute le virement car la requête semble legitime

Méthodes de prévention

1. Token CSRF (Synchronizer Token Pattern)

Le serveur genere un token unique par session, inclus dans chaque formulaire :

<form method="POST" action="/virement">
  <input type="hidden" name="_csrf" value="abc123xyz789" />
  <input type="number" name="montant" />
  <button type="submit">Envoyer</button>
</form>

Le serveur vérifie que le token dans la requête correspond a celui de la session.

2. SameSite Cookies (le plus simple)

Set-Cookie: session=abc123; SameSite=Strict; Secure; HttpOnly
  • Strict : le cookie n'est jamais envoye sur les requêtes cross-site
  • Lax : envoye uniquement sur les navigations top-level (liens, pas formulaires)
  • None : envoye partout (requiert Secure)

3. Vérification des headers Origin/Referer

app.use((req, res, next) => {
  const origin = req.headers.origin || req.headers.referer;
  if (origin && !origin.startsWith('https://monsite.com')) {
    return res.status(403).json({ error: 'CSRF detected' });
  }
  next();
});

4. Double Submit Cookie

Envoyer le token CSRF à la fois dans un cookie et dans un header/body. Le serveur vérifie qu'ils correspondent.

CSRF et les API REST

Les API stateless utilisant des JWT dans le header Authorization (pas de cookies) ne sont pas vulnérables au CSRF, car le token n'est pas envoye automatiquement par le navigateur.

Frameworks et protection CSRF

La plupart des frameworks web intègrent une protection CSRF :

  • Laravel : @csrf dans les formulaires Blade
  • Django : {% csrf_token %} middleware
  • Express : csurf middleware
  • Next.js : SameSite cookies par défaut

Besoin d'aide technique ?

Decrivez votre projet pour des conseils personnalises par nos experts.

Recevoir des conseils

Questions fréquentes

Les API REST sont-elles vulnerables au CSRF ?
Non, si elles utilisent des JWT dans le header Authorization. Le CSRF exploite l'envoi automatique des cookies. Les tokens Bearer ne sont pas envoyes automatiquement.
SameSite=Lax suffit-il comme protection CSRF ?
Dans la majorite des cas, oui. Lax bloque les requetes POST cross-site tout en permettant la navigation normale. Strict est plus securise mais peut impacter l'experience utilisateur (pas de session apres un clic depuis un email).
Comment tester les vulnerabilites CSRF ?
Utilisez Burp Suite ou OWASP ZAP pour generer des requetes cross-site. Verifiez que vos formulaires POST sont proteges et que les cookies ont SameSite=Lax ou Strict.

Pages liées

Chaque semaine, le meilleur de la tech française

Tendances, salaires, outils et opportunités — directement dans votre boîte mail.

Gratuit. Desabonnement en un clic. Pas de spam.