XSS vs CSRF : différences, exemples et prévention

XSS vs CSRF : la différence en un coup d'oeil

Quelle est la différence entre XSS et CSRF ? Le XSS fait exécuter le script de l'attaquant par le site vulnérable, dans le navigateur de la victime, avec un accès complet à la page. Le CSRF fait envoyer par le navigateur de la victime une requête vers le site vulnérable depuis une page contrôlée par l'attaquant, en abusant du fait que les cookies partent automatiquement. Le XSS peut lire et agir ; le CSRF ne peut qu'agir.

Qu'est-ce que le XSS (cross-site scripting) ?

Le cross-site scripting se produit quand une application insère une entrée utilisateur dans une page sans l'encoder : le navigateur interprète alors cette entrée comme du HTML ou du JavaScript au lieu de l'afficher comme du texte. Le script injecté s'exécute sous l'origine du site, avec accès à la page, à son DOM, à ses cookies non-HttpOnly et à tout ce que l'utilisateur peut faire.

Il existe en trois variantes, détaillées dans notre guide du cross-site scripting :

• XSS réfléchi : la charge voyage dans la requête (souvent un paramètre d'URL) et est renvoyée telle quelle. La victime doit ouvrir un lien piégé.
• XSS stocké : la charge est enregistrée (un commentaire, une bio) et servie à chaque visiteur. Aucun lien à envoyer, ce qui en fait le type le plus dangereux.
• XSS basé sur le DOM : le JavaScript du site écrit une donnée non fiable, comme location.hash, dans la page. Le serveur ne voit parfois jamais la charge.

Un exemple d'attaque XSS

Une page de recherche renvoie la requête sans l'encoder :

<!-- PHP vulnérable -->
<p>Résultats pour : <?php echo $_GET['q']; ?></p>

Envoyez q=chaussures et la page affiche "Résultats pour : chaussures". Envoyez q=<script>alert(document.domain)</script> et le navigateur interprète cela comme une vraie balise script et l'exécute. La preuve est une alerte inoffensive, mais le même point d'appui permet à un script de lire la page et d'envoyer des requêtes au nom de l'utilisateur connecté. Si le cookie de session n'est pas marqué HttpOnly, il peut aussi le lire directement, d'où l'importance de ce seul attribut.

Qu'est-ce que le CSRF (cross-site request forgery) ?

Le cross-site request forgery pousse le navigateur d'un utilisateur connecté à envoyer une requête sensible vers un site qui lui fait confiance. La page de l'attaquant construit la requête, le navigateur y attache les cookies de la victime, et le serveur voit une session valide et exécute l'ordre. Rien n'est injecté dans le site vulnérable.

Comment fonctionne une attaque CSRF

1. La victime se connecte à bank.example. Un cookie de session est stocké dans son navigateur.
2. Elle ouvre la page de l'attaquant dans un autre onglet, toujours connectée.
3. Cette page tire une requête vers bank.example, cachée dans une balise image ou un formulaire auto-soumis.
4. Le navigateur y attache automatiquement le cookie de session, car c'est ainsi que fonctionnent les cookies pour toute requête vers ce domaine.
5. Le serveur la traite comme légitime, incapable de distinguer une requête forgée d'une vraie.

Un exemple d'attaque CSRF

Pour un endpoint qui accepte un GET, une balise image cachée sur la page de l'attaquant suffit :

<!-- Sur la page de l'attaquant -->
<img src="https://bank.example/transfer?to=mallory&amount=1000" style="display:none">

Pour un endpoint POST, un formulaire auto-soumis fait le même travail :

<form action="https://bank.example/transfer" method="POST" id="f">
  <input type="hidden" name="to" value="mallory">
  <input type="hidden" name="amount" value="1000">
</form>
<script>document.getElementById('f').submit();</script>

Comment XSS et CSRF diffèrent en profondeur

Le XSS peut-il mener au CSRF ?

Oui, et c'est pour cela que le XSS est plus grave que le CSRF. Un token CSRF fonctionne parce que la page externe de l'attaquant ne peut pas le lire. Mais le XSS s'exécute dans l'origine : le script injecté peut donc lire le token directement dans la page et l'attacher à une requête forgée. La requête paraît alors parfaitement légitime, token compris.

Autrement dit, un point d'appui XSS traverse les défenses CSRF sans effort. La conclusion pratique : si un site a du XSS, vous avez le CSRF gratuitement, plus la lecture des données. Corriger le CSRF ne fait rien contre le XSS, et un XSS non corrigé sape vos protections CSRF.

Comment prévenir le XSS et le CSRF

Les deux demandent des défenses différentes. Les tokens CSRF ne font rien contre le XSS, et l'encodage de sortie ne fait rien contre le CSRF. Il faut les deux jeux en place.

Prévenir le XSS

• 🔒 Encodage de sortie selon le contexte. Échappez la donnée utilisateur pour le contexte exact où elle atterrit (corps HTML, attribut, JavaScript, URL). C'est le correctif qui met fin à la faille. Laissez le framework échapper par défaut et auditez chaque échappatoire comme dangerouslySetInnerHTML ou un innerHTML brut.
• 🛡️ Content Security Policy. Une CSP stricte qui bloque les scripts inline est une solide seconde couche. Elle ne corrige pas la faille, mais elle peut empêcher une charge de s'exécuter quand une passe entre les mailles.
• 🍪 Cookies de session HttpOnly. Empêchent le JavaScript de lire le cookie de session, neutralisant la forme la plus directe de vol de session. À associer à Secure.
• ✅ Assainissez le HTML riche avec une bibliothèque éprouvée. Si les utilisateurs soumettent légitimement du HTML, passez-le par DOMPurify plutôt qu'un filtre maison.

Prévenir le CSRF

• 🎫 Tokens anti-CSRF. Placez un token imprévisible par session dans chaque formulaire sensible et vérifiez-le côté serveur. Une page externe ne peut ni le lire ni le deviner.
• 🍪 Cookies SameSite. SameSite=Lax (défaut de Chrome depuis 2020) empêche les cookies de partir sur la plupart des requêtes cross-site ; Strict est plus serré. À traiter comme défense en profondeur, pas comme seul contrôle, car c'est un comportement du navigateur, pas une vérification serveur.
• 🔍 Vérifications Fetch Metadata et Origin. Rejetez les requêtes sensibles dont l'en-tête Sec-Fetch-Site ou Origin montre qu'elles viennent d'un autre site.
• 🔐 Ré-authentification pour les actions critiques. Exigez un mot de passe ou une étape de confirmation pour les opérations sensibles comme les virements.

Impact concret

Les deux attaques reviennent sans cesse parce que la confiance qu'elles abusent, un navigateur qui fait confiance au contenu et un serveur qui fait confiance à un cookie, est inscrite dans le fonctionnement du web. Voyez le classement actuel dans l'OWASP Top 10:2025.

Comment tester le XSS et le CSRF

Pratiquez avec des labs dédiés

Considérations légales et éthiques

• Ne testez que sur des systèmes qui vous appartiennent, des cibles d'entraînement volontairement vulnérables, ou le périmètre autorisé d'un bug bounty ou d'une mission.
• Utilisez des preuves inoffensives. Ne déployez pas de charges lisant les données de vrais utilisateurs pour démontrer l'impact.
• Si vous trouvez une faille dans l'application d'autrui, signalez-la via son processus de divulgation et arrêtez-vous là.
• Les labs et cours liés ici existent pour pratiquer légalement l'attaque comme la défense.