Cross-Site Scripting (XSS).

Le Cross-Site Scripting (XSS) survient lorsqu'une application web renvoie ou stocke des entrées non fiables dans ses réponses sans échappement adapté au contexte, laissant du JavaScript contrôlé par l'attaquant s'exécuter dans le navigateur de la victime sous l'origine du site — héritant de ses cookies, de l'accès au DOM et des privilèges de même origine. Les trois classes sont le XSS réfléchi (charge renvoyée depuis la requête), le XSS stocké (charge persistée côté serveur, par exemple dans un commentaire) et le XSS basé sur le DOM (le point d'injection se trouve dans le JavaScript côté client, comme innerHTML ou document.write).

La démonstration canonique de la portée du XSS stocké est le ver Samy : le 4 octobre 2005, Samy Kamkar a déposé une charge JavaScript sur son profil MySpace qui l'ajoutait comme ami et se recopiait sur le profil de chaque visiteur. Il a infecté plus d'un million de comptes en moins de 20 heures — le ver à propagation la plus rapide de l'époque — et a entraîné une perquisition du Secret Service ainsi qu'un plaidoyer de culpabilité pour crime. Le XSS reste un pilier de l'OWASP Top 10, intégré à l'A03:2021 (Injection).

Les défenses sont superposées : un encodage de sortie adapté au contexte (HTML, attribut, JS, URL), une Content-Security-Policy stricte avec des nonces ou des hachages pour bloquer le script en ligne, l'auto-échappement des frameworks (React, Angular), les Trusted Types pour verrouiller les points d'injection DOM dangereux, et les cookies HttpOnly/SameSite pour limiter le vol de session. La validation des entrées aide, mais ne suffit pas à elle seule.

flowchart LR
  A[L'attaquant soumet une charge] --> W[L'app web stocke ou renvoie l'entrée]
  W -->|Sortie non échappée| V[Le navigateur de la victime rend la page]
  V --> X[Le script de l'attaquant s'exécute sous l'origine du site]
  X --> S[Vol de cookies/session, keylogging, rebond]