Écrire un rapport XSS qui se corrige

Un rapport XSS peut être techniquement vrai et pratiquement inutile.

Le symptôme est connu : une capture d'écran, une phrase alarmante, un payload collé sans contexte, puis une recommandation générique du style "sanitize user input". L'équipe de développement doit alors deviner la route, le paramètre, le contexte de rendu, la transformation exacte et le correctif attendu. C'est une perte de temps pour tout le monde.

Un rapport utile réduit l'incertitude.

Montrer le flux, pas seulement l'effet

La preuve d'impact compte, surtout en bug bounty. Mais pour corriger, il faut comprendre le flux.

Un bon rapport devrait expliquer :

• où la donnée entre ;
• où elle ressort ;
• dans quel contexte elle est interprétée ;
• quelles protections existent déjà ;
• pourquoi elles ne suffisent pas ;
• quel correctif précis est recommandé.

On n'a pas besoin d'écrire un roman. Il faut juste donner assez de matière pour qu'un développeur puisse retrouver le bug sans refaire tout l'audit.

Entrée : paramètre q sur /search
Sortie : attribut data-query dans le composant ResultHeader
Contexte : attribut HTML, valeur réutilisée côté client après hydratation
Observation : l'encodage serveur est correct, mais la réinjection frontend change le contexte

Cette note vaut plus qu'une longue introduction sur les dangers du XSS.

Les étapes de reproduction doivent survivre au temps

Un rapport est souvent lu après plusieurs jours, parfois après une release qui a déjà changé l'interface. Les étapes doivent donc être stables.

Indiquer "aller sur la page et coller le payload" ne suffit pas. Il faut préciser l'environnement, l'état nécessaire, le compte utilisé si pertinent, les permissions, les paramètres exacts, le navigateur, et les transformations appliquées.

Les collections de xsspayloads peuvent aider ici : on garde la recette de transformation, puis on nettoie les données sensibles avant de partager.

Recommandations : éviter les slogans

"Sanitize input" est rarement une bonne recommandation. La plupart des XSS se corrigent à la sortie, selon le contexte. Pour du texte HTML, on encode en texte. Pour un attribut, on respecte les règles d'attribut. Pour une URL, on valide le schéma et on encode correctement. Pour du HTML riche, on utilise une bibliothèque de sanitization maintenue avec une configuration stricte.

Une recommandation exploitable ressemble à :

Remplacer l'insertion HTML du composant par une insertion texte.
Si le rendu HTML est requis, appliquer une sanitization allowlist avant le sink, puis ajouter un test de régression sur ce flux.

Ce n'est pas plus long. C'est beaucoup plus utile.

Le ton compte aussi

Un rapport n'est pas une démonstration de supériorité. L'équipe qui reçoit le bug travaille peut-être avec du legacy, des contraintes produit, des dépendances difficiles à migrer. Être précis sans être théâtral aide à faire corriger plus vite.

Le but final n'est pas d'avoir raison. Le but est que la vulnérabilité disparaisse proprement.