Recherche
Rechercher dans le blog.
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.
Tester le XSS sans sortir du cadre autorisé
Un outil XSS n'a de sens que dans un cadre clair : propriété, autorisation écrite, bug bounty, CTF ou environnement de formation.
Écrire un rapport XSS qui se corrige
Un bon rapport XSS ne cherche pas seulement à prouver l'impact. Il donne à l'équipe les informations nécessaires pour corriger sans deviner.
DOM XSS : debugger le flux réel, pas le HTML source
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.
Templates personnalisés XSS : utiles, mais dangereux sans garde-fous
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.
Collections locales : rendre les tests XSS reproductibles
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.
Playground XSS : isoler sans se raconter d'histoires
Un playground XSS est utile pour observer le comportement du navigateur, mais il ne reproduit jamais toute la complexité d'une application réelle.
WAF et filtres XSS : ce qui casse en production
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.
CSP ne répare pas une XSS
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.
Encodage XSS : l'ordre des transformations compte
URL encoding, entités HTML et Base64 ne sont pas interchangeables. En test XSS, l'ordre d'application change complètement le résultat.
Avant le payload, comprendre le contexte
Un test XSS sérieux commence par le contexte d'injection. HTML, attribut, JavaScript, URL ou CSS ne se testent pas avec la même logique.
Pourquoi un générateur XSS doit rester côté client
Le choix client-side n'est pas un détail produit pour un outil XSS. C'est une décision de sécurité, de confidentialité et de confiance opérationnelle.