XSS Basé sur le DOM.

Le XSS basé sur le DOM (Type 0) est une faille de cross-site scripting dont la cause racine réside entièrement dans le code côté client. Le terme a été forgé par Amit Klein en 2005 dans l'article « DOM Based Cross Site Scripting or XSS of the Third Kind ». Une source de confiance — location.hash, location.search, document.referrer, window.name, postMessage ou localStorage — se propage sans assainissement vers un sink dangereux tel que innerHTML, document.write, eval, setTimeout ou jQuery.html(). Comme la charge malveillante voyage souvent dans le fragment de l'URL (après le #), elle n'est jamais envoyée au serveur, rendant la faille invisible aux WAF, aux journaux serveur et à la plupart des scanners de XSS réfléchi.

L'impact réel est considérable : le XSS DOM est apparu à maintes reprises dans des balises publicitaires et d'analyse, dans des gestionnaires postMessage qui font confiance à des données cross-origin, et dans d'anciens sélecteurs jQuery ($(location.hash), corrigé dans la CVE-2011-4969 pour les versions antérieures à 1.6.3). L'analyse menée par Google a révélé que la majorité des XSS dans ses produits était basée sur le DOM, ce qui a motivé la création de Trusted Types. Défenses : privilégier les sinks inertes comme textContent et setAttribute ; assainir avec DOMPurify ou l'API Sanitizer intégrée ; imposer Trusted Types ainsi qu'une Content Security Policy stricte ; et exécuter des outils de suivi de teinte (taint-tracking) qui tracent les flux de la source vers le sink lors de la revue de code.

flowchart LR
  A["Source<br/>location.hash / postMessage"] --> B[JS côté client<br/>lit la valeur]
  B --> C{Assaini ?}
  C -->|"textContent / DOMPurify"| D[Rendu sans danger]
  C -->|"chaîne brute vers innerHTML,<br/>eval, document.write"| E[Le sink exécute la charge]
  E --> F[Le script de l'attaquant s'exécute<br/>dans la session de la victime]
  F --> G[Vol de cookies, prise de<br/>contrôle de compte, keylogging]
  E -.->|Trusted Types bloque| H[TypeError, aucune exécution]