Checklist développeur : réduire les XSS sans théâtre
Une checklist pragmatique pour corriger et prévenir les XSS : encodage de sortie, APIs DOM sûres, sanitization maintenue, CSP et tests de régression.
La prévention XSS n'a pas besoin d'être mystique. Elle demande surtout de la discipline près des points de rendu.
Les équipes perdent du temps quand elles cherchent une règle universelle. Il n'y en a pas. Une donnée affichée comme texte, placée dans un attribut, passée dans une URL, injectée dans du HTML riche ou utilisée par un composant JavaScript ne se protège pas de la même façon. Le contexte gouverne le correctif.
Voici une checklist courte, pensée pour des équipes qui doivent livrer sans transformer chaque ticket en thèse AppSec.
Encoder à la sortie selon le contexte
L'encodage de sortie reste la base. Pas parce que c'est élégant, mais parce que c'est là que l'application sait enfin dans quel contexte la donnée va être interprétée.
Pour du texte HTML, utilisez les mécanismes d'échappement du framework. Pour un attribut, laissez le moteur de rendu gérer l'échappement ou utilisez une API qui le fait correctement. Pour une URL, validez le schéma, construisez l'URL avec des primitives prévues pour ça, puis encodez les composants. Pour JavaScript inline, la meilleure option est souvent de ne pas en produire.
Si une donnée non fiable doit traverser plusieurs contextes, arrêtez-vous et redessinez le flux. C'est généralement un signal de dette.
Éviter les sinks dangereux
Certaines APIs demandent une justification explicite. Rendu HTML brut, insertion de markup, construction de scripts, manipulation directe d'attributs sensibles : tout cela mérite une revue.
Dans beaucoup de cas, le correctif le plus robuste est banal :
Avant : insérer une chaîne comme HTML
Après : insérer la même valeur comme texte
Ce changement n'impressionne personne en démonstration, mais il supprime une classe entière de problèmes.
Sanitizer seulement quand il faut vraiment du HTML
Si le produit doit accepter du HTML utilisateur, utilisez une bibliothèque maintenue et une allowlist stricte. Pas une regex. Pas une fonction utilitaire héritée dont personne ne connaît les limites.
La configuration compte. Autoriser trop d'attributs ou trop de protocoles revient à déplacer le bug. Il faut aussi tester les cas métier : éditeur riche, copier-coller depuis Word, Markdown converti, intégrations embed, migrations de contenu ancien.
Ajouter CSP comme filet, pas comme excuse
Une CSP stricte réduit l'impact des régressions. Elle peut bloquer des scripts inline, limiter les origines et rendre certains chemins d'exploitation beaucoup plus difficiles. Elle ne remplace pas l'encodage correct.
Si votre politique contient 'unsafe-inline' partout, commencez par comprendre pourquoi. Parfois il y a une vraie contrainte legacy. Parfois c'est juste resté après un incident de build.
Tester les flux qui ont déjà cassé
Chaque XSS corrigée devrait produire un test de régression. Pas forcément un grand test end-to-end fragile. Parfois un test de composant suffit. Parfois il faut valider une route complète parce que la vulnérabilité venait d'une interaction entre serveur et frontend.
Les payloads et pipelines conservés dans xsspayloads peuvent servir de base de reproduction, puis être traduits en tests automatisés.
La sécurité durable est rarement spectaculaire. Elle ressemble à des APIs sûres, des tests qui restent, des exceptions CSP supprimées, et des développeurs qui connaissent le contexte dans lequel ils affichent une donnée.