Avant le payload, comprendre le contexte

Le mauvais réflexe en XSS consiste à chercher "le payload qui marche". C'est rassurant, rapide, et presque toujours trop vague.

Un payload n'existe jamais seul. Il arrive dans un contexte : texte HTML, attribut, URL, bloc JavaScript, template côté client, CSS, JSON injecté dans une page. Chaque contexte a ses règles d'échappement, ses séparateurs, ses caractères dangereux et ses faux positifs. Si on ignore ça, on finit par tester au hasard.

Le contexte décide du test

Un champ reflété dans du texte HTML n'a rien à voir avec un champ placé dans un attribut. Dans le premier cas, on regarde surtout si les caractères de balisage sont échappés. Dans le second, il faut comprendre le guillemet utilisé, la présence éventuelle d'un encodage HTML, et la manière dont le navigateur reconstruit le DOM.

Même chose pour une injection dans une URL. Le navigateur, le framework, le routeur et parfois le serveur peuvent normaliser différemment :

valeur saisie -> encodage applicatif -> template -> parse navigateur -> DOM final

Le DOM final est souvent la seule vérité utile. Le HTML source ment parfois, surtout avec des frameworks qui hydratent, réécrivent ou déplacent des attributs.

Ce que xsspayloads aide à éviter

Le générateur n'est pas là pour remplacer l'analyse. Il sert à garder une discipline de test.

On choisit un contexte. On applique une chaîne d'encodage. On observe comment l'application transforme l'entrée. On note ce qui est neutralisé et ce qui traverse. Cette méthode est plus lente qu'un copier-coller depuis une vieille liste, mais elle produit des résultats exploitables dans un rapport.

Un bon rapport ne dit pas seulement "XSS possible". Il explique où la donnée entre, où elle ressort, quel contexte est atteint, quelle protection manque, et pourquoi le correctif doit porter sur l'encodage de sortie plutôt que sur un filtre improvisé.

Les faux positifs coûtent cher

Beaucoup de tests XSS échouent parce que l'auditeur confond réflexion et exécution. Voir une chaîne revenir dans la page ne suffit pas. Voir un caractère spécial survivre ne suffit pas non plus. Il faut prouver que le navigateur interprète la donnée dans un contexte actif.

À l'inverse, certaines protections donnent une fausse impression de sécurité. Un filtre peut bloquer une forme précise et laisser passer une variante liée au contexte. Une sanitization peut être correcte côté serveur, puis contournée par un composant frontend qui réinjecte la valeur avec une API dangereuse. Le problème n'est pas toujours au même endroit que le symptôme.

La bonne question

La question utile n'est pas "quel payload utiliser ?"

La question utile est : "dans quel parseur ma donnée arrive-t-elle, et quelles transformations subit-elle avant d'y arriver ?"

Une fois cette réponse claire, le payload devient presque secondaire. Il n'est plus une formule magique. C'est juste une sonde adaptée au contexte.