Fiche de révision : Cross-Site Scripting (XSS)
Mise à jour le 7 août 2026
Le sink à éviter
// Dangereux : interprete la valeur comme du HTML actif
element.innerHTML = valeurNonFiable;Le réflexe qui neutralise le risque
// Sûr : traite toujours la valeur comme du texte brut
element.textContent = valeurNonFiable;Astuce
Une charge comme <img src=x onerror="..."> s’exécute via innerHTML, mais s’affiche comme texte littéral et inoffensif via textContent. Une seule ligne fait toute la différence.
L'essentiel
Qu'est-ce qu'une XSS, et où s'exécute le code injecté ?
Une XSS fait exécuter du code par le navigateur d'une victime, pas par le serveur. Le code hérite des privilèges et du contexte de la victime dans la page, contrairement à une injection SQL qui vise le serveur.
Quelle est la différence entre une XSS réfléchie et une XSS stockée ?
Réfléchie : la donnée vient d'un paramètre de requête, renvoyée telle quelle sans être stockée, une victime doit cliquer sur un lien piégé. Stockée : la charge est enregistrée côté serveur et s'exécute pour tous les visiteurs de la page, sans lien nécessaire.
Qu'est-ce qu'une XSS basée sur le DOM ?
Une faille entièrement côté client : une donnée non fiable (source, ex. un champ de saisie) est écrite dans le DOM d'une façon dangereuse (sink, ex. innerHTML), sans qu'aucune donnée n'ait besoin de transiter par un serveur.
Pourquoi un payload <script> inséré via innerHTML ne s'exécute-t-il pas ?
Les navigateurs rendent inertes les balises <script> insérées via innerHTML, par protection intégrée. Les charges réelles utilisent plutôt des gestionnaires d'évènements comme onerror ou onload, qui s'exécutent normalement dès leur insertion.
Comment une XSS permet-elle de voler une session utilisateur ?
Un script injecté lit document.cookie et exfiltre sa valeur vers un serveur contrôlé par l'attaquant, qui la réutilise ensuite comme son propre cookie pour usurper la session de la victime, sans jamais connaître son mot de passe.
Quel attribut de cookie neutralise précisément ce vol de session ?
HttpOnly : il rend le cookie invisible à document.cookie, donc illisible par un script injecté, quelle que soit la famille de XSS exploitée par ailleurs.
Quelle est la protection de fond contre la XSS ?
L'échappement contextuel de toute donnée non fiable avant insertion dans la page, et préférer textContent à innerHTML dès qu'aucun HTML n'a besoin d'être inséré : textContent ne réalise jamais d'interprétation HTML.
Que change une Content-Security-Policy stricte face à une XSS ?
Sans 'unsafe-inline', elle bloque l'exécution des scripts et gestionnaires d'évènements inline (dont onerror), neutralisant de nombreuses charges même si l'échappement a échoué quelque part. Elle complète l'échappement, elle ne le remplace pas.