Protection contre les CSRF dans les SPA Vue
Cookies SameSite, jetons CSRF dans Axios et modèle du double cookie soumis
Protection contre les CSRF dans les SPA Vue est une leçon Vue Academy gratuite sur CoddyKit. Ceci est la leçon 3 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 Vue Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Vue Academy comprend 4 leçons au total.
Qu’est-ce que CSRF
La falsification de requête intersites (CSRF) pousse le navigateur d’un utilisateur connecté à effectuer une requête indésirable qui modifie l’état de votre site, en utilisant les cookies que le navigateur envoie automatiquement. L’attaquant ne peut pas lire les réponses, mais il peut provoquer des effets secondaires comme des virements ou des suppressions.
Pourquoi les cookies le permettent
Si l’authentification repose sur un cookie de session, le navigateur le joint à chaque requête destinée à votre domaine, y compris celles déclenchées depuis un site malveillant. Sans protection supplémentaire, le serveur ne peut pas distinguer une requête falsifiée d’une requête légitime.
L’attribut de cookie SameSite
Définir SameSite sur le cookie indique au navigateur quand l’envoyer entre sites. SameSite=Strict empêche l’envoi du cookie pour toute requête intersite, ce qui bloque directement la plupart des attaques CSRF.
Set-Cookie: session=...; SameSite=Strict; Secure; HttpOnlyStrict ou Lax
Strict offre la meilleure sécurité, mais peut déconnecter les utilisateurs lorsqu’ils arrivent depuis des liens externes. Lax envoie le cookie uniquement lors des navigations GET de premier niveau, ce qui constitue un compromis courant.
Le modèle du jeton synchroniseur
Une défense en profondeur ajoute un jeton CSRF que l’attaquant ne peut pas connaître. Le serveur émet un jeton ; le client doit le renvoyer dans les requêtes qui modifient l’état.
Cookie à double soumission
Une approche courante pour une SPA : le serveur place le jeton CSRF dans un cookie lisible (non-HttpOnly). Le client le lit et le renvoie dans un en-tête. Le serveur vérifie que les deux valeurs correspondent.
Set-Cookie: XSRF-TOKEN=abc123; SameSite=Strict; SecureLire le jeton depuis le cookie
Lisez la valeur du cookie CSRF avec une petite fonction utilitaire dans votre application Vue.
function getCookie(name) {
const match = document.cookie.match(
new RegExp("(^| )" + name + "=([^;]+)")
);
return match ? decodeURIComponent(match[2]) : null;
}
const token = getCookie("XSRF-TOKEN");Définir l’en-tête des requêtes
Envoyez le jeton dans un en-tête personnalisé tel que X-CSRF-Token pour chaque requête qui modifie l’état (POST, PUT, PATCH, DELETE).
await fetch("/api/transfer", {
method: "POST",
headers: { "X-CSRF-Token": token },
body: JSON.stringify(payload)
});En-têtes par défaut d’Axios
Avec Axios, définissez l’en-tête une seule fois comme valeur par défaut afin que chaque requête l’inclue automatiquement.
import axios from "axios";
axios.defaults.headers.common["X-CSRF-Token"] = getCookie("XSRF-TOKEN");Prise en charge xsrf intégrée d’Axios
Axios peut automatiser cette opération : configurez les noms du cookie et de l’en-tête, et il lit le cookie puis définit l’en-tête à votre place.
const api = axios.create({
xsrfCookieName: "XSRF-TOKEN",
xsrfHeaderName: "X-CSRF-Token",
withCredentials: true
});Pourquoi un en-tête personnalisé est utile
Les navigateurs empêchent les sites d’une autre origine de définir des en-têtes personnalisés sans pré-vol CORS autorisé. Exiger X-CSRF-Token signifie qu’une requête intersite falsifiée ne peut pas l’inclure ; le serveur la rejette donc.
Vérification rapide
Quel attribut de cookie réduit le plus directement les attaques CSRF à lui seul ?
Récapitulatif
CSRF exploite les cookies envoyés automatiquement pour falsifier des requêtes qui modifient l’état. Définissez SameSite=Strict sur les cookies d’authentification comme défense principale, puis ajoutez un jeton CSRF : lisez-le depuis un cookie et envoyez-le dans chaque requête de mutation via un en-tête X-CSRF-Token, configuré une seule fois comme valeur par défaut d’Axios ou au moyen des options xsrf intégrées d’Axios.
Questions Fréquemment Posées
La leçon « Protection contre les CSRF dans les SPA Vue » est-elle gratuite ?
Oui — le texte complet de « Protection contre les CSRF dans les SPA Vue » 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 Vue Academy, passe à CoddyKit PRO. Le cours Vue Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Protection contre les CSRF dans les SPA Vue » ?
Cookies SameSite, jetons CSRF dans Axios et modèle du double cookie soumis Tu pratiques Vue 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 Vue Academy ?
Aucune expérience préalable n'est requise. Vue 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 3 sur 4.
Combien de temps prend la leçon « Protection contre les CSRF dans les SPA Vue » ?
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 Vue Academy ?
Oui. Chaque leçon Vue 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 dans Vue
- Content Security Policy (CSP) avec Vue
- Protection contre les CSRF dans les SPA Vue
- Modèles d’authentification sécurisée