Blog
Articles, guides et nouveautés.
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.
Un outil XSS n'a de sens que dans un cadre clair : propriété, autorisation écrite, bug bounty, CTF ou environnement de formation.
Un bon rapport XSS ne cherche pas seulement à prouver l'impact. Il donne à l'équipe les informations nécessaires pour corriger sans deviner.
En DOM XSS, le code source de la page raconte souvent une histoire incomplète. Le flux réel se lit dans le DOM, les sources JavaScript et les mutations.
Les templates accélèrent les tests répétitifs, mais ils peuvent aussi figer de mauvaises hypothèses et produire des résultats trompeurs.
Sauvegarder des payloads n'a d'intérêt que si l'on conserve le contexte, les transformations et les observations qui permettent de reproduire le test.
Un playground XSS est utile pour observer le comportement du navigateur, mais il ne reproduit jamais toute la complexité d'une application réelle.
Les filtres XSS génériques bloquent parfois des tests simples, puis ratent le vrai contexte vulnérable. En production, le coût opérationnel arrive vite.
Content Security Policy réduit l'impact de certaines XSS, mais ne corrige pas l'injection. La nuance compte dans les audits et les correctifs.