DOM XSS : debugger le flux réel, pas le HTML source

Le HTML source est un mauvais témoin pour beaucoup de DOM XSS.

Il montre ce que le serveur a envoyé. Il ne montre pas toujours ce que le navigateur exécute après hydratation, routing côté client, composants dynamiques, parsing de fragments d'URL ou récupération d'état depuis le stockage local. Dans les applications modernes, la donnée dangereuse peut ne jamais apparaître dans le HTML initial.

Elle arrive plus tard.

Sources, sinks, transformations

Une analyse DOM XSS sérieuse commence par trois mots : source, sink, transformation.

La source est l'endroit où la donnée non fiable entre dans le JavaScript : location.search, location.hash, postMessage, stockage local, réponse API, attribut data, état global, paramètre de route. Le sink est l'API qui peut interpréter cette donnée : rendu HTML brut, navigation, insertion d'URL, écriture dans un attribut sensible, exécution indirecte.

Entre les deux, il y a les transformations. Et c'est souvent là que le bug se cache.

source -> decode -> parse -> merge state -> render -> sink

Un audit qui saute directement au sink rate les erreurs de normalisation. Un audit qui regarde seulement la source ne sait pas si la donnée devient dangereuse.

Le DOM final tranche

Pour valider un comportement, il faut inspecter le DOM final et les mutations. Les DevTools sont souvent plus utiles que le rendu visuel. Un élément peut être invisible et quand même dangereux. Une valeur peut être échappée dans le HTML affiché mais réutilisée ensuite par un composant.

Le piège classique : une application échappe correctement côté serveur, puis un composant frontend lit le texte et le réinjecte dans une API plus permissive. Le rapport "le serveur échappe bien" est alors vrai et insuffisant.

Avec xsspayloads, les marqueurs et pipelines d'encodage servent à suivre cette donnée. On veut reconnaître la valeur après chaque étape, pas seulement voir si une alerte apparaît.

Reproduire sans bruit

Le DOM XSS produit beaucoup de faux signaux. Extensions navigateur, scripts tiers, hot reload en développement, overlays d'erreur, outils analytics : tout peut modifier la page.

Pour un test propre, il vaut mieux :

• désactiver les extensions non nécessaires ;
• tester dans un profil navigateur dédié ;
• noter l'URL exacte et l'état de stockage ;
• comparer avant et après hydratation ;
• vérifier les erreurs console et les violations CSP.

Ces détails font rarement la une du rapport, mais ils évitent les démonstrations impossibles à reproduire.

Le correctif vit près du sink

Le bon correctif DOM XSS consiste souvent à changer l'API utilisée ou à assainir strictement avant le sink. Remplacer une insertion HTML par une insertion texte est beaucoup plus fiable qu'ajouter un filtre regex en amont.

Quand du HTML utilisateur est vraiment nécessaire, il faut une sanitization maintenue, configurée explicitement, et testée sur les cas métier. Pas une fonction maison écrite un vendredi soir.

Le DOM XSS n'est pas mystérieux. Il est juste moins visible. Il demande de suivre la donnée jusqu'au navigateur réel, là où les hypothèses rencontrent le parseur.