XSS réfléchie : injecter via l'URL
10 min · Débutant · 7 août 2026
Le trajet d’une XSS réfléchie
Imagine une page de résultats de recherche qui affiche le terme recherché, extrait directement de l’URL :
https://exemple.test/recherche?q=injection+sqlSi le serveur insère la valeur de q dans la page sans l’échapper, la page générée ressemble à :
<p>Résultats pour : injection sql</p>Un attaquant qui contrôle la valeur de q contrôle donc une partie du HTML renvoyé. Il ne lui reste qu’à convaincre une victime de cliquer sur un lien contenant sa charge :
https://exemple.test/recherche?q=<img src=x onerror="voleSession()">Pourquoi « réfléchie »
Le serveur ne fait que refléter (renvoyer) la valeur reçue, sans jamais la conserver. C’est ce qui distingue cette famille des deux autres : rien n’est stocké, la charge n’existe que le temps de cette requête précise, et seule une personne qui clique sur le lien piégé est affectée.
Info
C’est aussi ce qui rend une XSS réfléchie plus difficile à exploiter à grande échelle qu’une XSS stockée : il faut convaincre chaque victime de cliquer sur un lien spécifique, souvent via un e-mail ou un message trompeur.
La démonstration
Le bac à sable ci-dessous simule ce que fait le serveur une fois la requête reçue : il prend une valeur (représentant le paramètre q déjà extrait de l’URL) et l’insère directement dans la page.
<!-- HTML -->
<p>Resultats de recherche pour : <span id="zone"></span></p>
// JS
// Simule le parametre "q" deja extrait de l'URL par le serveur,
// puis reinjecte tel quel dans la page (c'est la faille)
const parametreRecu = "<img src=x onerror=\"console.log('XSS reflechie executee')\">";
document.getElementById('zone').innerHTML = parametreRecu;Modifie parametreRecu pour construire ta propre charge. Tant que le serveur (ici simulé) ne fait aucune vérification, n’importe quelle valeur atteint la page telle quelle.